> The standard is explicit that the argument must be EOF or an unsigned > char. There is no way to support both true 8bit locales and > magically fix this.
No way for ctype.h to do so independent of the rest of the system. But it's not at all hard to fix it from a libc design perspective; you just need to choose a value for EOF that is out of range for signed char. > '\xff' in Latin1 is a letter for example and EOF is not. But nothing says (signed char)'\xff' == EOF. Nothing except existing practice, that is; the C spec chose (rightly, IMO) to support existing practice in this regard. > I'm still shocked by how many developers have been using C for 20 > years and still manage to not use ctype.h correctly... I've seen worse. I've even corresponded with someone holding the curious delusion that uncast NULL was suitable as a stdarg pointer argument, apparently believing that all pointer types had to be sufficiently similar, at least in an argument list, that this was possible. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
