Can characters ever be promoted to 'unsigned int'?

[chrisbazley]

Hi,

I have been re-reading section A6.1 'Integral Promotion' of K & R 2nd
edition with reference to section A4.2 'Basic Types'. As an academic
exercise, I am wondering whether a standards-compliant implementation
might exist in which 'int' cannot represent all the values of a
character; in other words, whether a character can ever be promoted to
'unsigned int' during expression evaluation.

This would only happen if SCHAR_MAX > INT_MAX or UCHAR_MAX > INT_MAX.
The former seems highly unlikely because it implies sizeof(signed
char) > sizeof(int). The latter seems more likely because it has the
weaker requirement that sizeof(unsigned char) >= sizeof(int).

The answer to question 1.1 of the comp.lang.c FAQ asserts "something
like the relation sizeof(char) <= sizeof(short) <= sizeof(int) <=
sizeof(long) <= sizeof(long long) is guaranteed" (with a caveat about
storage requirements not necessarily equating to numeric range).

I have often seen similar claims but I can't find such a guarantee in
appendix A of K&R, which merely says "Longer integers provide at least
as much storage as shorter ones" . It doesn't appear to preclude
SCHAR_MAX > INT_MAX. The closest I can find is the guarantee that
"when sizeof is applied to a char, the result is 1". This requires
integer objects to use at least as much storage space as characters
(or else their size couldn't be represented).

Have I missed something?

 

[Tim Rentsch]

Hi,

I have been re-reading section A6.1 'Integral Promotion' of K & R 2nd
edition with reference to section A4.2 'Basic Types'. As an academic
exercise, I am wondering whether a standards-compliant implementation
might exist in which 'int' cannot represent all the values of a
character; in other words, whether a character can ever be promoted to
'unsigned int' during expression evaluation.

An (unsigned char) may promote to (unsigned int) rather than (int).
A (signed char) always promotes to (int), never (unsigned int).
Of course (char) is allowed to have the same range as either
(unsigned char) or (signed char), so it's possible for (char)
to promote to (unsigned int), but only if (char) has the same
range as (unsigned char) [and only if (unsigned char) promotes
to (unsigned int)].

This would only happen if SCHAR_MAX > INT_MAX or UCHAR_MAX > INT_MAX.
The former seems highly unlikely because it implies sizeof(signed
char) > sizeof(int). The latter seems more likely because it has the
weaker requirement that sizeof(unsigned char) >= sizeof(int).

The answer to question 1.1 of the comp.lang.c FAQ asserts "something
like the relation sizeof(char) <= sizeof(short) <= sizeof(int) <=
sizeof(long) <= sizeof(long long) is guaranteed" (with a caveat about
storage requirements not necessarily equating to numeric range).

I have often seen similar claims but I can't find such a guarantee in
appendix A of K&R, which merely says "Longer integers provide at least
as much storage as shorter ones" . It doesn't appear to preclude
SCHAR_MAX > INT_MAX. The closest I can find is the guarantee that
"when sizeof is applied to a char, the result is 1". This requires
integer objects to use at least as much storage space as characters
(or else their size couldn't be represented).

Have I missed something?

Get this:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

and read section 6.2.5, paragraph 8.

 

[Peter Nilsson]

Hi,

I have been re-reading section A6.1 'Integral Promotion'
of K & R 2nd edition with reference to section A4.2 'Basic
Types'. As an academic exercise, I am wondering whether a
standards-compliant implementation might exist in which
'int' cannot represent all the values of a character;
in other words, whether a character can ever be promoted to
'unsigned int' during expression evaluation.

They are not academic. DSP chips typically have sizeof(int)
== 1. Whether char promotes to unsigned int is entirely
dependant on whether (plain) char is signed or unsigned.

This would only happen if SCHAR_MAX > INT_MAX

That can't happen since integer ranges for signed types
must be subsets ordered by rank.

or UCHAR_MAX > INT_MAX.

This can not only happen, it's not uncommon on freestanding
implementations.

The former seems highly unlikely

It's impossible.

because it implies sizeof(signed char) > sizeof(int).

Which is impossible since sizeof(signed char) is always 1
and no object has 0 bytes.

The latter seems more likely because it has the
weaker requirement that sizeof(unsigned char) >= sizeof(int).

No, sizeof (unsigned char) is also 1. The sizeof operater
yields the number of bytes, not the number of octets, and a
character type is always 1 byte by definition.

The answer to question 1.1 of the comp.lang.c FAQ asserts
"something like the relation sizeof(char) <= sizeof(short)
<= sizeof(int) <= sizeof(long) <= sizeof(long long) is
guaranteed"

It isn't, but you're very unlikely to find an implementation
where the relations don't hold.

 

[Mark Hobley]

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
and read section 6.2.5, paragraph 8.

For the benefit of those of us who hate having to fire up a pdf reader, just
to try and follow a usenet thread, that paragraph simply reads:

For any two integer types with the same signedness and different conversion
rank, the range of values of the type with smaller integer conversion rank is
a subrange of the values of the other type.

Mark.

 

[Tim Rentsch]

For the benefit of those of us who hate having to fire up a pdf reader, just
to try and follow a usenet thread, that paragraph simply reads:

For any two integer types with the same signedness and different conversion
rank, the range of values of the type with smaller integer conversion rank is
a subrange of the values of the other type.

I intentionally posted just a link and a section reference, to
get OP (and perhaps others) into the habit of looking up things
in the Standard directly. It's better if people rely on reading
the Standard themselves, coming to c.l.c only when they're
confused or can't find what they're looking for. Teach a man
to fish, and all that. I have no problem with someone asking
a simple question the first time, or maybe even the second or
third time; at the same time, I want to encourage everyone who
visits the newsgroup to try to find answers themselves.