On Fri, Jan 03, 2003 at 04:31:05PM -0800, Mike Cheponis wrote:

 > > > > >     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.
 > 
 > Precisely!

Just because a value is a valid int, does not mean it is a valid
argument to isalpha().

 > > 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.
 > 
 > Again: > > FreeBSD and BSDI don't have this bug; why does NetBSD ?

Your question does not make sense, as the behavior you are complaining
about is not a bug, and it is totally incorrect of you to characterize
it as such.

 > I was NOT misusing isalpha().  This is my point!  ;-)

If you are passing an illegal argument to isalpha(3), then you certainly
are misusing it.

Try doing:

	fprintf(NULL, "this is a test.\n");

That will (correctly) crash.  Even though NULL is a perfectly valid
pointer argument, it is *not* a valid argument to fprintf().  By passing
such an invalid argument to fprintf() you can not argue that you are not
misusing that routine.  Why is isalpha() any different?

 > Explain to me how silent data corruption occurs when isalpha() behaves
 > correctly (my defintion of correct)?  I just want to know if the damn int
 > is an alpha or not!  Is that TOO MUCH TO ASK ???

Yes, it is, if you're passing an int which is outside the allowed range.

isalpha() is defined to tell you if an int *which falls in a specific
valid range* is an alpha.  The interface is not meant to process arbitrary
numbers, and so you should not use it to do so.

 > > 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.
 > 
 > 
 > Excuse me!
 > 
 > What I have been saying is that there are better-behaved implementations,
 > like those on FreeBSD and BSDI, and I believe that NetBSD's implemention
 > should be similarly behaved.

"Better behaved" according to you, maybe.  The NetBSD behavior is going
to find the programming bug faster.

Face it, you wrote a buggy program.  NetBSD should not change its behavior
to compensate for your buggy program.  At the very most, perhaps a sentence
clarifying the behavior in the manual page is warranted, but certainly
nothing more than that.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>