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