DragonFly BSD
DragonFly commits List (threaded) for 2005-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: ctype bug

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Thu, 7 Jul 2005 01:53:21 +0200
Mail-followup-to: commits@crater.dragonflybsd.org

On Wed, Jul 06, 2005 at 04:45:08PM -0700, Matthew Dillon wrote:
> :*sigh* Which behaviour should be used instead? It can't return an error,
> :because this functions are not supposed to return errors. Second, it can't
> :return an arbitrary value, because that can be considered wrong too.
> :Third, it can't magically cast them to unsigned, because 255 is a valid letter
> :in UTF8, but also (signed)255 == EOF.
>     Joerg, just because the standard says undefined doesn't give us license
>     to allow an API function to randomly overflow an array and return garbage.
>     It just doesn't, and we aren't going to do it.  It's totally
>     inappropriate, in fact.  libc has to be more robust then that. 

It returns as much garbage as FreeBSD returned. Returning '0' for an invalid
argument is as invalid as any other value. Period. Anything else is silently
breaking programs. I gave you already an example why "supporting" negative char
values as input is giving wrong results. The code has to be fixed and nothing
else. This has nothing to do with being a purist, but simply that changing this
doesn't fix anything, but instead silently produces garbage.

If possible, I'd instruct ld to map a hole before the ctype tables and I'm
actually thinking about implementing that at run time.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]