SCHAR_MIN

[John Taylor]

Hello,

Why SCHAR_MIN == -127 in the C99 standard? I thought integer types
representation is two's complement, and that means that if I have 8 bits
I can represent values from -128 to +127...

Thanks.

 

[John Taylor]

The bitwise representation is not dictated by the C standard. Either
two's complement, ones complement or sign/magnitude is allowed.

Thanks, now I understood!

 

[Seebs]

Hello,

Why SCHAR_MIN == -127 in the C99 standard? I thought integer types
representation is two's complement, and that means that if I have 8 bits
I can represent values from -128 to +127...

Thanks.

Because the two's complement representation is not universal or guaranteed.

-s

 

[Peter Nilsson]

The bitwise representation is not dictated by the C standard.

Actually it is, as you say below...

Either two's complement, ones complement or sign/magnitude
is allowed.

And as it is implementation-defined, so the implementation must
document its choice.

It's a little ambiguous whether the one choice applies to all
signed integer types or each signed type can have a different
option.

Note that these are not the only possible representations
in general. For instance, an implementation is not free
to implement wide integer types with a normalised floating
point representation, even though it might be practical
to do so.

For this reason, the common minimum is indicated by *_MIN
and *_MAX macros.

They exist primarily because there is no other way for an
implementation to test the width of an integer in the
presence of potential padding bits.

Also note that an implementation with INT_MIN == -32767 may
still be using two's complement representation under C99.

 

[James Kuyper]

Actually it is, as you say below...


And as it is implementation-defined, so the implementation must
document its choice.

It's a little ambiguous whether the one choice applies to all
signed integer types or each signed type can have a different
option.

I don't think it's ambiguous; I think it's very clearly unspecified,
allowing the possibility of different choices for different signed types.

 

[Peter Nilsson]

I don't think it's ambiguous; I think it's very clearly
unspecified, allowing the possibility of different choices
for different signed types.

That's how I choose to interpret it since it calls for the most
defensive programming.

However, n1336 6.2.6.2p2 starts "For signed integer types...",
then mentiones the representations, then says "Which of these
applies is implementation-defined". That could be interpreted
as there being only one choice for all signed types.

Further, p3 talks about the _implementation_ supporting
negative zeros. It's not clear that there is an arbitrary choice
for each signed type.

 

[Tim Rentsch]

I don't think it's ambiguous; I think it's very clearly unspecified,
allowing the possibility of different choices for different signed
types.

ambiguous: Open to more than one interpretation

Obviously some people read it differently than you
do, so there certainly is some ambiguity.

 

[Tim Rentsch]

Harumph! That's not how /I/ would define it!

*laughs* that was a good one.

Reminds me of this exchange on the Simpsons.

Marge: We could watch Rashomon again. You liked that one.

Homer: That's not the way I remember it.

 

[Tim Rentsch]

What's the link? The first was humour based on the phrase. Your one is
nothing like that.

Sorry, the similarity of self-reference isn't apparent?
To me they're very close. Although I have to admit that
Richard's comment made me laugh more.