Subject: Re: lib/34632
To: None <lib-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: David Brownlee <abs@NetBSD.org>
List: netbsd-bugs
Date: 09/27/2006 08:40:02
The following reply was made to PR lib/34632; it has been noted by GNATS.
From: David Brownlee <abs@NetBSD.org>
To: Antony Dovgal <antony@zend.com>
Cc: Quentin Garnier <cube@cubidou.net>,
Christos Zoulas <christos@zoulas.com>, gnats-bugs@NetBSD.org,
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 09:36:09 +0100 (BST)
On Wed, 27 Sep 2006, Antony Dovgal wrote:
> On 27.09.2006 11:37, Quentin Garnier wrote:
>> 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.
>
> Oh, I didn't know that a missing if(), which leads to different behaviour
> comparing to other OSes, means more portability. Tell me more about it. Does
> it also add more stability for you? Or consistency with other systems? Wow,
> what a nonsense.
The code should be identical on all systems - it just
doesn't send invalid values to isalpha(). What if one system
returned 0 for those values, another returned -1 and a
third returned 1. Any program passing invalid values to
isalpha() is by definition unportable, so changing it to
only pass valid values is the only way to guarantee
portability, even across systems which do not segfault on
invalid values.
Can you give an example of where you would want to pass an
invalid value to isalpha() apart from a programming error?
I'm not being sarcastic on that - I can believe there might
be a case, I just cannot see it from this end.
>>> >What's next? Handling NULL pointers in strcpy()?
>>>
>>> I don't care, sorry. As long as it works for me on Linux you can do
>>> everything you want in NetBSD.
>>
>> Now who's friendly, again?
>
> Surely segfault is the most user-friendly thing I can imagine.
It does make it obvious there is a bug in the code and it
also shows exactly on which line :) I agree its less friendly
for a user running the app with the bug, but it is likely
to be very helpful for a developer trying to track it down.
>>> Again, this is only my thoughts, you can do anything you like.
>>
>> I really prefer knowing about real bugs than hiding them.
>
> I personally prefer to deal with real bugs instead of OS weirdness caused by
> some purity reasons.
> But you don't seem to understand me, so I don't see any sense to keep
> arguing. Do whatever you like, it's free world.
Both approaches - explictly put in extra code in libc to
check for invalid values and handle them, or keep the code
in libc simpler and faster - are valid, both 100% comply
with the C standard, and both will allow correctly written
programs to run exactly as expected in the same way on all
systems.
The behaviour you prefer allows programs which call the
routine incorrectly to continue running, but with potentially
different behaviour across systems.
--
David/absolute -- www.NetBSD.org: No hype required --