Subject: Re: lib/19638: isalpha (3) bug
To: Mike Cheponis <mac@Wireless.Com>
From: Andrew Brown <>
List: netbsd-bugs
Date: 01/03/2003 22:52:40
>> >Precisely!
>> 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" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"       * "information is power -- share the wealth."