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