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 --