--=._50IHZ_bFEMSYC
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Mike Cheponis <mac@Wireless.Com> wrote:

> Ahh, who's to say it isn't "real-world"?  I found this NetBSD bug
> while using srandom() and random().

You still don't understand. For isalpha() et al. only a subset of int is
valid input, i.e. the set of unsigned char plus EOF.

> The NetBSD behaviour is wrong.

You don't like it, that's all.

> > > 1)  Here are the OSs that this program works without a problem:
> > > o Digital UNIX V4.0B  (Rev. 564); Tue Dec 14 15:43:30 EST 1999
> > > o FreeBSD 4.2-RELEASE #2: Sun Mar  4 12:11:05 PST 2001
> > > o BSDI BSD/OS 4.0 Kernel #6: Thu Jan 21 12:47:23 PST 1999

FWIW, here are my results:
The strings are the output of `uname -mrspv':
SunOS 5.8 Generic_108528-15 sun4u sparc
SunOS 5.9 Generic_112233-03 sun4u sparc
OSF1 V4.0 1229 alpha alpha (This V4.0F)
IRIX 6.2 03131015 IP22 mips

In all cases your program gets killed by a SIGSEGV and isalpha() does
return non-zero for many other values than [a-zA-Z].

> I did the tests, and your assertion is incorrect.  Here is the test
> prog:
> 
> int main()
Bad style.

> {
>   int c;
> 
>   for (c=0; c <= 0x7ffffff; c++){
You're assuming int has 32 bit?
 
>     if (isalpha(c)){printf ("%c(%d)\n",c); fflush(stdout);}
Bad style plus wrong printf() usage.

>   }
>   return 0;
Bad style.

> }
> 
> Both FreeBSD and BSDI produce exactly what one would expect: A-Z then
> a-z.(Digital unix was confused).

> > >     Feeding a routine in libc a perfectly valid int should NOT
> > >     cause the libc routine to segfault.  That is Bad.

This is totally bogus argument. Please, show me an *invalid* int.
isalpha() - like most other routines in libc - is not fool-safe, you
have to read the documentation before you use one routine and have to
follow its rules.

> ****NetBSD**** is abusing the interface by having libc crash when
> perfectly legal values of the type are sent to a routine in libc.
> 
> FreeBSD and BSDI don't have this bug; why does NetBSD ?

Would you ever have noticed your misuse of isalpha() if your program had
not crashed? So you prefer silently corrupting data over an obvious
crash pointing you directly to your problem?

You do not only want the implementation not to crash you also want it to
decide whether a non-character is"alpha" or not. This is out of the
scope of isalpha(). It's not supposed to handle such values and relying
on the behaviour a specific implementation might do for invalid input is
simply a bad habbit, i.e. not portable.

Christian

--=._50IHZ_bFEMSYC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (NetBSD)

iD8DBQE+FhsI0KQix3oyIMcRAqLNAKCeqXQHVne23Doa/zUTqWh17qD+cgCeLpKD
bKsDQTsc+RL4F1vYd0ibQD0=
=DvRL
-----END PGP SIGNATURE-----

--=._50IHZ_bFEMSYC--