Subject: Re: lib/34632
To: Antony Dovgal <antony@zend.com>
From: Quentin Garnier <cube@cubidou.net>
List: netbsd-bugs
Date: 09/27/2006 09:37:41
--VxJb6WgA6MoA+arP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 27, 2006 at 11:24:42AM +0400, Antony Dovgal wrote:
> On 27.09.2006 03:37, Christos Zoulas wrote:
> >On Sep 27,  1:50am, antony@zend.com (Antony Dovgal) wrote:
> >-- Subject: Re: lib/34632: isalpha() and possibly other ctype functions=
=20
> >segfa
> >
> >| On 27.09.2006 01:10, Christos Zoulas wrote:
> >| >  This is not a bug. Undefined includes "segmentation fault". This is=
=20
> >why
> >| >  we cast to (unsigned char) in our sources.
> >|=20
> >| Ok, but I'm afraid you'd need to add this to the docs and inform such=
=20
> >projects as: SQLite, PCRElib, libxml2 and many more which do not cast it=
=20
> >to (unsigned char) either.
> >| Currently I can see similar "expected" behaviour only on Solaris, whic=
h=20
> >also segfaults in this case.
> >| Other systems (AIX, MacOS, various Linuxes) have chosen a user-friendl=
y=20
> >way and return 0.
> >
> >Being friendly is a slippery slope.=20
>=20
> I would not expect a function that accepts *integer* to segfault if this=
=20
> argument has a "wrong" value.
> Would you?

It depends who you are friendly to.  If Linux had been as friendly to
the author of the code, then the bug would have been fixed.

Passing an incorrect value to isalpha() is a bug.  It should not happen.
If the author is careless enough to do that, who knows how many bugs are
piling right after to use that 0 returned on Linux in wrong ways?

I am sorry that as a user you have to bear with the poor habits of bad
programmers, but in NetBSD we usually choose to help people write
portable code.

This is the same reason our pthreads lib aborts when the behaviour it
should have is undefined.

> >What's next? Handling NULL pointers in strcpy()?
>=20
> I don't care, sorry. As long as it works for me on Linux you can do=20
> everything you want in NetBSD.

Now who's friendly, again?

[...]
> >As far as the documentation goes we can say "undefined behavior including
> >Segmentation faults". Is that good enough?
>=20
> I already explained you why I think it's not good enough.
> I mean, *I* can live with that because I don't use it, but "undefined=20
> value" in my pov doesn't include "segfault", I expect to get an undefined=
=20
> integer value, that's it.

It's not "undefined value", it really is "undefined behaviour".  There's
a difference.

[...]
> Again, this is only my thoughts, you can do anything you like.

I really prefer knowing about real bugs than hiding them.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

--VxJb6WgA6MoA+arP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iQEVAwUBRRoqRdgoQloHrPnoAQK2IAf/cbL/BnvIHNNgk+3xrE7tR/EWL46BAVsc
uos9zmuKFJXTRkCzWBb7o96jwb4uC+tSVtI49ztHWkgMeoYF4hpr7i4oEA0EauSD
7va7S8rnqMFiFH2wmY2IaSBfDmxZ5JxucZ2zNcVeX0Jq0Z8rrKZwTZq4dUfl/PcY
iJUCzBZ35KFtzjbEOO6F6VnkLeN8x9pSOmVooalmeEJuz25So4hq9H1ywqjvoZ6g
KXlGYSDq/8doaad4v5u6vxLfe4Ak0SbTT1m8Fwwih/ix2QmZfSpRqZi62s7fwgDK
ChqHWxpeHBlDhf7Atf4WkX/vdvkgXPWZm09aENRyMOg+YpFY10jRkg==
=oipP
-----END PGP SIGNATURE-----

--VxJb6WgA6MoA+arP--