plain int and signed int

[happy]

As signed char and plain char can be different if plain char is
unsigned in a particular implementaion,
Can signed int and plain int be different or are they guaranteed to be
same?

 

[Nick Keighley]

As signed char and plain char can be different if plain char is
unsigned in a particular implementaion,
Can signed int and plain int be different or are they guaranteed to be
same?

an int is a signed int

 

[Keith Thompson]

As signed char and plain char can be different if plain char is
unsigned in a particular implementaion,
Can signed int and plain int be different or are they guaranteed to be
same?

Plain char and signed char are always distinct types. They may or
may not have the same representation.

"signed int" and "int" are simply two different names for the same
type, with one exception: the name "int", when it's the type of a bit
field, may refer either to signed int or to unsigned int. (Thanks to
Richard Heathfield for pointing that out; I would have forgotten it.)

 

[happy]

Plain char and signed char are always distinct types.  They may or
may not have the same representation.

Even if plain char is signed, then also are plain and signed char
distinct ?
I mean can they have different representations?

 

[Ben Pfaff]

Even if plain char is signed, then also are plain and signed char
distinct ?
I mean can they have different representations?

If plain char is signed, then plain char and signed char have the
same representation.

If plain char is unsigned, then plain char and unsigned char have
the same representation.

 

[Eric Sosman]

Even if plain char is signed, then also are plain and signed char
distinct ?
I mean can they have different representations?

Signed char is a type. Unsigned char is another type,
whose representation is necessarily different from that of
signed char.

Plain char is a third type. It has the same representation
as one of the first two -- either signed char or unsigned char --
but is a distinct type nonetheless.

Many people find this weird, for a simple reason: It's weird.
But that's the way it is, mostly for historical reasons.

If it's any comfort, consider that on many systems there are
only two representations shared among the three distinct types
short, int, and long: Usually short and long are different, and
int has the same representation as one or the other. But short
and int are distinct types even on systems where they have the
same representation, while int and long are distinct even on
systems where *they* have the same representation.

 

[Keith Thompson]

Even if plain char is signed, then also are plain and signed char
distinct ?
Yes.

I mean can they have different representations?

No.

If plain char is signed, then plain char and signed char are two
disinct types with exactly the same range and representation.

Some examples:

char c = 'c';
signed char s = 's';
/* The actual values are not important */

c = s; /* ok, involves an implicit type conversion */
s = c; /* ok, as above */
/* Note that the implicit type conversions above don't do
any actual work.
*/

char *pc = &c;
signed char *ps = &s;
pc = ps; /* constraint violation, requires a diagnostic */
ps = pc; /* constraint violation, requires a diagnostic */

Since C permits implicit conversions between any two arithmetic
types, the fact that two such types are distinct *usually* isn't very
important. But pointers to two such distinct types are themselves
distinct pointer types, and there are no implicit conversions for
distinct pointer types (other than void* and some special cases
for null pointer constants)

 

[bartc]

unless it's a bit-field, in which case you'd better specify which one you
want, signed or unsigned. Otherwise the implementation gets to choose.

I didn't realise a field of one bit could be signed. Seems to work though.

 

[lawrence.jones]

I didn't realise a field of one bit could be signed. Seems to work though.

Just be aware that it might only be able to hold one value, which isn't
very useful in most cases.

 

[Keith Thompson]

Just be aware that it might only be able to hold one value, which isn't
very useful in most cases.

I think that it could hold either 0 or -1 on a 2's-complement system.
On a 1's-complement or sign-and-magnitude system, it could only hold
+0 or -0.

Is that what you had in mind?

 

[Andrew Poelstra]

I think that it could hold either 0 or -1 on a 2's-complement system.
On a 1's-complement or sign-and-magnitude system, it could only hold
+0 or -0.

Is that what you had in mind?

But on a 1's complement system could you assign 0 and 1 to the field,
and differentiate between them even if they are -0 and +0?

Or could -0 be a trap representation and knock out your program?

 

[Keith Thompson]

But on a 1's complement system could you assign 0 and 1 to the field,
and differentiate between them even if they are -0 and +0?

Not portably, I think. Converting the value 1 to the bit field's type
yields an implementation-defined value or raises an
implementation-defined signal. It's likely to do something sensible,
but there are no guarantees.

I can't think of a good reason to use a 1-bit signed bit field, even
if its behavior were well-defined.

Or could -0 be a trap representation and knock out your program?

I think -0 can be a trap representation, but if it is it can't be the
result of a conversion of a valid value.

 

[Tim Rentsch]

I think that it could hold either 0 or -1 on a 2's-complement system.
On a 1's-complement or sign-and-magnitude system, it could only hold
+0 or -0.

Is that what you had in mind?

Or, in all three cases (s/m, 1's complement, 2's complement), the
representation different from +0 could be a trap representation.

 

[Tim Rentsch]

Not portably, I think. Converting the value 1 to the bit field's type
yields an implementation-defined value or raises an
implementation-defined signal. It's likely to do something sensible,
but there are no guarantees.

I can't think of a good reason to use a 1-bit signed bit field, even
if its behavior were well-defined.


I think -0 can be a trap representation, but if it is it can't be the
result of a conversion of a valid value.

Of course it can. The implementation-defined signal produced
by the out-of-range conversion can produce whatever representation
it wants to.

 

[bartc]

I think that it could hold either 0 or -1 on a 2's-complement system.
On a 1's-complement or sign-and-magnitude system, it could only hold
+0 or -0.

Would a bitfield necessarily have to use the same integer representation as
ordinary integer values?

 

[Tim Rentsch]

INTERNATIONAL STANDARD
ISO/IEC 9899

6.2.6.2 Integer types

3 If the implementation supports negative zeros,
they shall be generated only by:
* the &, |, ^, ~, <<, and >> operators with arguments that
produce such a value;
* the +, -, *, /, and % operators where one argument is a
negative zero and the result is zero;
* compound assignment operators based on the above cases.

Right, but an out-of-range value is being converted:

6.3.1.3 Signed and unsigned integers

3 Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.

The implementation-supplied signal handler for this signal is
free to use &, |, etc, to generate a result for the conversion.
Remember the semantics of default signal handlers are
implementation-defined.

 

[Tim Rentsch]

Would a bitfield necessarily have to use the same integer
representation as ordinary integer values?

Debatable. My reading is that all integer types have to follow
the same basic choices (2's complement vs 1's complement vs s/m,
whether or not the distinguished value is a trap representation)
in how signed types (including signed bitfields) are represented,
but I don't know if there's any sort of consensus on the
question.

 

[Eric Sosman]

Debatable. My reading is that all integer types have to follow
the same basic choices (2's complement vs 1's complement vs s/m,
whether or not the distinguished value is a trap representation)
in how signed types (including signed bitfields) are represented,
but I don't know if there's any sort of consensus on the
question.

7.18.1.1 requires that exact-width signed integer types
(if they exist) must use two's complement representation.
Therefore, if all signed integer types must follow the same
scheme for representing negative values, either

1) Ones' complement and signed magnitude representations
are forbidden, or

2) There are no exact-width integer types.

Note that (2) implies CHAR_BIT is not 8, 16, 32, or 64.

 

[Phil Carmody]

INTERNATIONAL STANDARD
ISO/IEC 9899

6.2.6.2 Integer types

3 If the implementation supports negative zeros,
they shall be generated only by:
. the &, |, ^, ~, <<, and >> operators with arguments that
produce such a value;
. the +, -, *, /, and % operators where one argument is a
negative zero and the result is zero;
. compound assignment operators based on the above cases.

So '-0' cannot evaluate to negative 0? Eeep, that's a bit counter-
intuitive.

Phil

 

[Tim Rentsch]

Clarification: all integer types _in any particular implmentation_.
Obviously different implementations can make different choices.

7.18.1.1 requires that exact-width signed integer types
(if they exist) must use two's complement representation.
Therefore, if all signed integer types must follow the same
scheme for representing negative values, either

1) Ones' complement and signed magnitude representations
are forbidden, or

2) There are no exact-width integer types.

In fact I think that's right -- an implementation can have exact-width
integer types, or use a { 1's complement, s/m } representation, but
not both.

Note that (2) implies CHAR_BIT is not 8, 16, 32, or 64.

No, an implementation can have CHAR_BIT be any of those values but
use a representation other than 2's complement, in which case it
won't have exact-width integer types. N1256 is explicit that
having a 2's complement representation is a pre-requisite for
requiring the exact width types be defined.