| www.delorie.com/archives/browse.cgi | search |
Corinna Vinschen wrote:
> I didn't explain that well enough. The problem is not the char value
> 0xff if it's defined as unsigned char value as expected by the ctype
> functions. The problem is how to treat this value if it's given as
> signed char value to the ctype functions by broken applications and for
> backward compatibility. In this special case it's -1 and so it has the
> same value as EOF. The change in the library should not result in
> breaking an existing application. So the value -1 when given to the
> ctype functions should always return the equivalent value for EOF, not
> the value for the character 0xff.
Are you not implying we should break correct applications for
"backward-compatibility" with broken ones? The values 0xff and -1 are
entirely distinct inputs as far as isblank() is concerned.
"The isblank() function shall test whether c is a character of class blank in
the program's current locale"
"The c argument is a type int, the value of which the application shall ensure
is a character representable as an unsigned char or equal to the value of the
macro EOF. If the argument has any other value, the behavior is undefined."
How does SED cope with this on glibc systems, which also use signed chars
and have had locale fully-supported for some time?
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/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |