Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Sep 2009 09:16:29 +0400
From:      Andrey Chernov <ache@nagual.pp.ru>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, Dag-Erling Sm??rgrav <des@des.no>, svn-src-all@freebsd.org, src-committers@freebsd.org, "Simon L. Nielsen" <simon@freebsd.org>
Subject:   Re: svn commit: r196752 - head/lib/libc/stdtime
Message-ID:  <20090904051629.GA88503@nagual.pp.ru>
In-Reply-To: <20090904115255.Q48987@delplex.bde.org>
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> <20090904115255.Q48987@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 04, 2009 at 01:42:04PM +1000, Bruce Evans wrote:
> The patch is missing the corresponding text for wctype functions
> (argmuments of type wint_t generally give undefined behaviour unless
> their value is representable as a wchar_t or equal to the value of
> WEOF).  In FreeBSD, wint_t has the same type as wchar_t and that type
> is int, so bugs in this area are latent (unportable code might run
> on FreeBSD, and there might be problems with the sign bit and/or with
> WEOF being indistinguishable from a valid wide char encoding.

Yes, having the same note for wctype family will be nice too.

> It should be something like "if the value to be
> passed is represented as a signed char" ...  I don't know a good easy
> way to fix "must be cast ... to avoid sign-extension errors".  The
> value must be converted to one representable as an unsigned char to
> work, but that is not always possible, and blindly casting may give
> a wrong value.  

> Exotic machines include:

I think, "exotic machines" examples you mention already brokes too many
other aspects regarding to char manipulating, so nobody will really make
such machines with standard-compliance C compiler on them :)

> Sign extension for passing a signed char is not an error.  The error is
> passing a negative value.

Yes. Perhaps 'Never pass negative arg there, including sign-extended char' 
or something alike.

> Neither C99 nor POSIX gives any advice.  They just say that the behaviour
> is undefined if the value is not representable as an unsigned char or
> equal to the value of EOF.

Yes, I already mention that.

> % Index: lib/libc/locale/isrune.3
> % Index: lib/libc/locale/digittoint.3
> % Index: lib/libc/locale/isascii.3
> % Index: lib/libc/locale/toascii.3

Yes, those ones works with int. I don't pay attention to them in 
the whole patch :(

About other wording nuances mentioned in your reply, I don't have an 
opinion, everybody knows my English is poor :)

-- 
http://ache.pp.ru/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090904051629.GA88503>