Hi, On 2021-10-02 21:05:17 -0700, Andres Freund wrote: > Got the build part working (although the state of msvc compatible openssl > distribution on windows seems a bit scary). However the ssl tests don't > fully succeed: > > https://cirrus-ci.com/task/6264790323560448?logs=ssl#L655 > > I didn't see code in the bf client code running the test so perhaps that's > not too surprising :/ > > Did you run those tests on windows?
As you can see in the test output, every mismatch prints the whole file, despite only intending to show the tail. Which appears to be because the windows portion of 3c5b0685b921 doesn't actually work. The reason for that in turn is that afaict the setFilePointer doesn't change the file position in a way that affects perl. Consequently, if I force the !win32 path, the tests pass. At first I assumed the cause of this is that while the setFilePointer() modifies the state of the underlying handle, it doesn't actually let perl know about that. Due to buffering etc perl likely has its own bookeeping about the position in the file. There's some pretty clear hints in https://perldoc.perl.org/functions/seek But the problem turns out to be that it's bogus to pass $fh to setFilePointer(). That's a perl handle, not an win32 handle. Fixing that seems to make the tests pass. Why did 3c5b0685b921 choose to use setFilePointer() in the first place? At this point it's a perl filehandle, so we should just use perl seek? Leaving the concrete breakage aside, I'm somewhat unhappy that there's not a single comment explaining why TestLib.pm is trying to use native windows APIs. Isn't the code as-is also "leaking" an open IO::Handle? There's a CloseHandle($fHandle), but nothing is done to $fh. But perhaps there's some perl magic cleaning things up? Even if so, loks like just closing $fh will close the handle as well... Greetings, Andres Freund
