Date: Thu, 3 Sep 2009 16:03:46 +0200 From: Joerg Sonnenberger <joerg@britannica.bec.de> To: svn-src-all@freebsd.org Subject: Re: svn commit: r196752 - head/lib/libc/stdtime Message-ID: <20090903140346.GA11785@britannica.bec.de> In-Reply-To: <86vdk0upmh.fsf@ds4.des.no> References: <200909020456.n824uUqQ082136@svn.freebsd.org> <20090902070808.GA1290@arthur.nitro.dk> <20090902084002.GA17325@nagual.pp.ru> <867hwgcwvo.fsf@ds4.des.no> <20090903084325.GA65192@nagual.pp.ru> <86zl9c9z05.fsf@ds4.des.no> <20090903115416.GB448@britannica.bec.de> <86vdk0upmh.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 03, 2009 at 03:25:26PM +0200, Dag-Erling Smørgrav wrote: > > This is actually not good enough. ISO C doesn't specify whether plain > > char is signed or unsigned. > > This is FreeBSD. Our char is signed. On systems where it isn't (IRIX > is the only one I know of), the cast is a no-op. GCC's default for ARM is unsigned. Just to name the most popular platform. I don't know if FreeBSD has local patches, but I expect a non-trivial amount of code is ported from/to ARM systems as well. > > > Also, isascii is the only exception to this rule, so the change for that > > is wrong. > > No. The fact that isascii() accidentally returns the correct answer > even in the absence of a cast is irrelevant. Passing a signed char to > isascii() invokes undefined behavior. To quote SUS: The isascii() function shall return non-zero if c is a 7-bit US-ASCII character code between 0 and octal 0177 inclusive; otherwise, it shall return 0. Joerg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090903140346.GA11785>