Subject: Re: lib/34632
To: Christos Zoulas <email@example.com>
From: Antony Dovgal <firstname.lastname@example.org>
Date: 09/27/2006 11:24:42
On 27.09.2006 03:37, Christos Zoulas wrote:
> On Sep 27, 1:50am, email@example.com (Antony Dovgal) wrote:
> -- Subject: Re: lib/34632: isalpha() and possibly other ctype functions segfa
> | On 27.09.2006 01:10, Christos Zoulas wrote:
> | > This is not a bug. Undefined includes "segmentation fault". This is why
> | > we cast to (unsigned char) in our sources.
> | Ok, but I'm afraid you'd need to add this to the docs and inform such projects as: SQLite, PCRElib, libxml2 and many more which do not cast it to (unsigned char) either.
> | Currently I can see similar "expected" behaviour only on Solaris, which also segfaults in this case.
> | Other systems (AIX, MacOS, various Linuxes) have chosen a user-friendly way and return 0.
> Being friendly is a slippery slope.
I would not expect a function that accepts *integer* to segfault if this argument has a "wrong" value.
> 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.
I just pointed you to the problem which doesn't exist in other systems.
You can fix it or you can ignore it - it's your choice.
> The best way is to submit patches and feed them back to the maintainers.
I guess maintainers are able to add and if() statement, that should not a be problem and I don't have NetBSD sources near at hand.
> As far as the documentation goes we can say "undefined behavior including
> Segmentation faults". Is that good enough?
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 value" in my pov
doesn't include "segfault", I expect to get an undefined integer value, that's it.
And looking at the other peoples code it seems that my pov is quite popular.
Again, this is only my thoughts, you can do anything you like.