Re: [Mingw-users] Msys-perl vs EBADF on fclose()

On 3/30/2011 8:53 AM, Earnie wrote:
> A strong case has been made for this change but the fact is the perl
> code is still wrong based on the documented function of fclose.

The culprit is actually MSys' close() implementation, which is used
under the hood by its implementation of fclose, as well (I think).

Yes, but...apparently MSys is the only platform on which close() behaves
in this legal, but non-intuitive, manner.  When the de facto standard
behavior differs from the de jure standard behavior, it just makes life
harder to insist on "fixing" all extant clients, like perl, that appear
to depend on the de facto, rather than the de jure, standard.

> With
> this statement I am not saying this patch should not be applied to MSYS,
> in fact, I think it should.

That was my understanding...but I think Cesar was waiting for other
opinions.  I gave mine; and a push for a 1.0.17 containing that fix to
come out soon.

> Patches to resolve the issue in perl should
> be made upstream as well, correct?

In perl-5.8.8, when current perl development is on 5.12.x or 6.0/parrot?
 For a bug that is exposed only on a "walled garden" private platform
like msys?  No, I don't think so.

And frankly, "solving" the problem -- rather than just papering over it
-- is going to be quite challenging.  It seems that there is a lot of
code "out there" that assumes successful system calls don't 'mess with'
the value of errno.  As it happens, some of the errno issues LRN and I
see with perl are bubbled up from the underlying zlib and bzip2 libraries.

I used the attached patch (and reverting the other EBADF "fix"), with
the following results:
	#1: there was NO direct access to msys's close() function, EXCEPT via
the msys_close() wrapper, by perl, libperl, or any of its extension code
*compiled as part of the perl build* [1]. This actually required a lot
of distributed patching, and isn't extensible to user-installed perl
modules.
	#2: It adds a new export, msys_close() to the libperl API, which we'll
need to maintain in perpetuity.
	#3: And it didn't fix the problem with the perl zlib and bzip2
extensions, because they delegate to the respective library code, which
internally call msys's close(), borking up errno.  There's no way a perl
wrapper around its own calls to close() can fix that.  So "fixing" this
means following a lot more rabbit trails in the code, in a lot more places.

So it looks like even "papering over" the bug is not entirely
straightforward, either.  I'll need to go digging in to zlib and libbz2
next. And who knows how many other libraries...and since msys::fclose
uses msys::close, I probably need to extend the "paper over" patch to
wrap fclose as well as close.  And socket(). and connect(). and anything
else that might, inside its msys implementation, also call close()
during successful operation.  And track down all uses of THOSE functions
in the dependent libraries as well.


[1] that is, if a perl extension links against a pre-compiled DLL such
as libgdbm, zlib, libcrypt, or libbz2...and THAT dll already calls
close() on its own, then there's nothing I can do about that from inside
perl.


OTOH, the attached patch did fix the observed errors with running the
autoconf test suite, so that's something.


Honestly, I just don't have time to tilt at this windmill anymore. By
MSys insisting on violating the de facto standard behavior ("well, it's
allowed by the de jure POSIX standard, so there! Pppbbbbhh!") it's just
making life harder for me.

I'd much rather simply "fix" the msys-1.0.dll to abide by the de facto
("don't mess with errno on success") standard, and punt -- basically,
release perl-5.8.8 with the requirement that users upgrade msys to
1.0.17, and not patch perl with respect to this issue at all.

--
Chuck