>> >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
garbage.

>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" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."