[ On Friday, January 3, 2003 at 14:15:31 (-0800), Mike Cheponis wrote: ]
> Subject: Re: lib/19638: isalpha (3) bug 
>
> But, but, but.... if a "character" were expected, then one should pass a
> char!  But, we pass an int because the original designers of C were confusing
> out-of-band information with data types.

No, I very seriously doubt they were confused about that.

First off, in C you can't pass a value that's only as wide as a char
(never in traditional C, and not without a prototype in ISO Standard C).  
The smallest (narrowest, bit-wise) parameter is normally an 'int'.

Secondly, I'm almost 100% certain that C's original designers were very
well aware of the fact that "(int) -1" is wider than a char (or unsigned
char).

However the history of how the isalpha() et al programming interfaces
were defined is really not the issue here -- all that's important is to
understand that the current version of IEEE POSIX still defines them in
such a way that old code can be re-compiled unchanged with new compilers
on new systems and it will still behave the same way for input values
within the defined range (give all other factors remain the same).

> ****NetBSD**** is abusing the interface by having libc crash when perfectly
> legal values of the type are sent to a routine in libc.

No, NetBSD's behaviour is completely well within that allowed by the
standard (IEEE Std 1003.1-2001, that is), and there is no bug and no
problem with a SIGSEGV resulting from an illegal input value to
isalpha() et al:

     The c argument is an int, the value of which the application shall
     ensure is 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.

Pay particular and very careful attention to that last sentence.  It has
a very special meaning in the context of an IEEE POSIX standards document.

Code which passes illegal values to isalpha() et al is broken, by
definition, and its users should fully expect it to terminate abnormally
with a SIGSEGV when it is run.  Those systems which do not detect such
violations and trigger a SIGSEGV may in fact cause even more bizzare and
unexpected behaviour and they are the ones that are buggy and broken,
not NetBSD.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>