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

[LRN <lr...@gm...>]

On 08.03.2011 15:42, Keith Marshall wrote:
> On 8 March 2011 11:38, LRN<lr...@gm...>  wrote:
>> On 08.03.2011 13:25, Albrecht Schlosser wrote:
>>> Disclaimer: I don't know the MSYS (code) internals, but I followed the
>>> discussion with interest. As has been clearly said, checking errno after
>>> a successful fclose() call is wrong, and should not be done.
>>>
>>> I'm trying to argue just from a logical programmer's view...
>>>
>>> On 08.03.2011 09:54, LRN wrote:
>>>>> There IS an ACTUAL bug in there - an attempt to fsync() a closed file.
>>> Then this one should be fixed independently of perl's suspected bug.
>>> Really.
>> Agreed.
>>
>>>>> I expect that it will be fixed, which will automagically fix errno to
>>>>> remain 0 (or whatever it was before the call). Thus, the point is
>>>>> largely moot. In the worst case i still can fix perl itself.
>>>>> Everything else is just bikeshedding.
>>> IMHO the point isn't moot. In the contrary: as a developer I'd be glad
>>> to have such a reproducible test case. With this, the first step should
>>> be to check what's going on in perl and fix this. Nobody guarantees that
>>> there can't be another case where fclose() *might* set errno to *any*
>>> other value in the future (this has been discussed here).
>> I'm pressing this for one simple reason: this close<->fsync thing in
>> msys i KNOW. I've FOUND it. I've TESTED it. I've found a way to fix it.
> Okay.  I'm playing Devil's Advocate here; I will continue to do so,
> while you persist in flogging this dead horse.
>
> I'll ask it again -- more directly this time: why are you so hell bent
> on "fixing" SOMETHING WHICH ISN'T BROKEN in the first place?  Sure, the
> way MSYS' fclose() is implemented may not be 100% rational, but, in
> terms of the applicable standards, IT ISN'T BROKEN!  Yes, it has a side
> effect which exposes a REAL bug, in the perl code you are hacking; THAT
> is the bug you should be tracking down, and fixing.
Why - easier/faster.
>>>> So i am led to think that the best (most compatible, less disturbing)
>>>> way to fix this is to simply comment-out fsync() rather than move it.
>>> Wrong conclusion.
> Like Albrecht says -- wrong conclusion; and yet, you still persist in
> pursuing it.
>
> Yes, you have identified something within MSYS which may not be entirely
> rational, but IT ISN'T A BUG (in the sense that it causes a problem for
> calling code, if that code is not itself defective).  Your "fix" does no
> more than modify a side effect, replacing one manifestation of undefined
> behaviour with another.  However, undefined behaviour means just that;
> your "fix" is NO MORE CORRECT than what it replaces, (because there is
> no "correct" implementation of undefined behaviour).  You haven't fixed
> anything.
>
> Sorry to be blunt about it; until you "get this", you are just wasting
> everybody's time, not least your own [*].
>
> [*] Yes, I'm sure the MSYS Developers will be grateful for the head's up
> on the odd behaviour, but SOMEBODY (maybe not you) needs to focus on the
> real bug here, (misuse of errno in perl code), rather than faffing at
> attacking some unexpected side effect, which is firmly in the realm of
> undefined behaviour but certainly not illegitimate, just because that
> side effect happens to expose the real bug.
>
I think this particular discussion is going nowhere. Actually, it's been 
going nowhere for some time. The problem is known. 2 of 3 possible 
solutions. Advantages and disadvantages of both (and some anticipated 
advantages/disadvantages of the third one) are presented. Dixi.

/me goes back to trying to install CPAN modules.