Corinna Vinschen wrote:
> On Apr 21 22:18, Eric Blake wrote:
>> The bug was that isblank(-1) was blindly treated as if were equivalent
>> with isblank(0xff), which, in some locales, is flat out wrong
>> (isblank(EOF) should always be 0, even when isblank(0xff) is well-defined
>> as 1). Broken apps can't tell the difference between isblank((char)0xff)
>> and isblank(EOF), but correct apps, like sed, CAN tell the difference
>> between 0xff and EOF in "int ch = getchar(); isblank(ch)" since getchar()
>> returns an int containing an unsigned char value (and not a char).
>>
>> Sed's infinite loop, then, was because of newlib/cygwin's bug - sed
>> reached the end of the file while trying to skip blanks, but because
>> isblank() was returning the wrong value for -1, sed thought that EOF was a
>> blank and kept trying to read the file instead of breaking out of the loop.
>
> Thanks for the explanation. Apparently I'm unable to explain this
> clearly enough.
When you referred to "broken applications" passing the wrong input to the
ctype function, I thought you meant SED by that.
Rereading your letter with the isFOO examples, I guess I should have been
able to infer it from that. It would have been a bit clearer (to me, at any
rate) if the answer to the question "How does SED cope with this on glibc
systems" had not been the quote from the header, which describes something
that newlib also does, but has said something like "Glibc makes sure that
entry -1 has the correct flag values for EOF rather than for
0xff-incorrectly-promoted, newlib resolves the clash in favour of using the
flag values for 0xff-incorrectly-promoted".
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
