Subject: Re: lib/19638: isalpha (3) bug
To: Mike Cheponis <mac@Wireless.Com>
From: Andrew Brown <email@example.com>
Date: 01/03/2003 22:52:40
>> feeding 135471234 to isalpha() and expecting a sensible result is like
>> feeding 135471234 to asin() and expecting a sensible result or like
>> calling fprintf() with NULL for the fp. all those inputs are outside
>> the proscribed domains of the functions. how a program handles that
>> is not defined by any standard. it is up to the program to make sure
>> that it does not exceed the domain of a function, not the system.
>I don't want to talk about pointers, I've already said that.
i don't see the point of not talking about pointers.
actually, i don't care if we talk about pointers. i was merely
pointing out a few more functions where there is a *defined* domain of
values you can pass as arguments. values outside of that domain may
give rise to undesirable behavior. you may get back a number that you
cannot use. you may get back the number 6. you may get a core dump.
you might print something to the wrong place.
>Even if I send 1123334 to asin(), I do -not- expect a segfault!
no, you should expect a nan, which may have any bit pattern under the
sun, so long as the exponent bits (iirc) indicate that the mantissa is
>And, to make my point, sending 12498454 to islpha works on FreeBSD and BSDI,
>giving the correct result (0).
that's their implementation, and as it is implemented, it is within
the constraints of the standard.
>What I'm trying to say is:
>1) libc "should" be held to higher standard.
ours is better than some, to be sure. ;-)
>2) Other respected implementations do this.
and is their choice to do so.
>3) We don't because of performance considerations? Hmmm....
i don't think that's really it.
|-----< "CODE WARRIOR" >-----|
firstname.lastname@example.org * "ah! i see you have the internet
email@example.com (Andrew Brown) that goes *ping*!"
firstname.lastname@example.org * "information is power -- share the wealth."