Subject: Re: lib/34632
To: None <lib-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Antony Dovgal <antony@zend.com>
List: netbsd-bugs
Date: 09/27/2006 07:15:05
The following reply was made to PR lib/34632; it has been noted by GNATS.

From: Antony Dovgal <antony@zend.com>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, tony2001@php.net
Subject: Re: lib/34632
Date: Wed, 27 Sep 2006 11:14:02 +0400

 On 27.09.2006 03:55, David Laight wrote:
 > The following reply was made to PR lib/34632; it has been noted by GNATS.
 > 
 > From: David Laight <david@l8s.co.uk>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: lib/34632: isalpha() and possibly other ctype functions segfault
 > Date: Wed, 27 Sep 2006 00:49:53 +0100
 > 
 >  On Tue, Sep 26, 2006 at 07:37:36PM -0400, Christos Zoulas wrote:
 >  > | Other systems (AIX, MacOS, various Linuxes) have chosen a user-friendly way and return 0.
 >  
 >  Are you sure ?
 
 Yes. I did check it out.
 Btw, I forgot to add FreeBSD to the list of systems that do not segfault.
 
 >  The isxxx() 'functions' are almost always implemented (and were designed to
 >  be implemented) as an array lookup checking for several bits.
 >  Since the domain of the functions is 'all the values of unsigned char + EOF'
 >  it is typically -1..255, calling the function with an -ve value in a
 >  signed char indexes off the front of the array.  If you are lucky this
 >  doesn't have the relevent bit(s) set and is a zero, it might have a
 >  bit set and return 1, it might not be mapped and so core dump.
 >  The standards allow 'undefined' behaviour - this includes formatting
 >  your hard disk or crushing your nuts.
 
 
 -- 
 Wbr, 
 Antony Dovgal