🚀 go-pugleaf

In article <DJ3o8r.J94@stdc.demon.co.uk> clive@stdc.demon.co.uk (Clive
D.W. Feather) writes:

|> In article <49uh73$hqp@gabi.gabi-soft.fr>, J. Kanze <kanze@gabi-soft.fr> wrote:
|> > Finally.  So I'm not the only one.  Not only do negative codes sound
|> > odd, they aren't acceptable input for the ctype functions.

|> The ctype functions are defined in terms of "characters cast to unsigned
|> char".

I know what the standard says.  Doesn't make my life any easier.

|> >|>  And can these expressions :
|> >|> (signed char) foo != 0
|> >|>  and
|> >|> (unsigned char) foo != 0
|> >|>  differ in result ?

|> Yes, they can.

|> > "When a value with
|> > integral type is converted to another integral type, if the value can be
|> > represented by the new type, its value is unchanged."  Implementation
|> > limits require that 0 be representable in all integral types.

|> Irrelevant. When a signed char is converted to an unsigned char,
|> negative values are converted in an implementation-defined manner. It
|> may well be that there is a negative value which converts to zero.
|> Provided that this value has the same properties as '\0' as far as the
|> ctype functions are concerned, this is conforming.

Oops.  My mistake, a non-0 value can become zero.  Zero cannot become
non-zero, but as you point out, that isn't sufficient to guarantee the
above.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone