2

Would I be correct to say that the underlying object representation (bit pattern) in each of the following definitions is the same?

char c = 240;
unsigned char c = 240;
signed char c = 240;

So, the signed-ness matters only when c is used in an expression (or casts)?

jogojapan
  • 68,383
  • 11
  • 101
  • 131
nightlytrails
  • 2,448
  • 3
  • 22
  • 33
  • 2
    I wouldn't be surprised if the `char` and `signed char` ones have undefined behavior. – melpomene Nov 30 '12 at 07:51
  • @melpomene, I'm pretty sure the signed overflow rule applies to initial values as well. In the case of `char`, it depends on the implementation as to whether it's signed or not. – chris Nov 30 '12 at 07:52
  • Your answer is there - http://stackoverflow.com/questions/8385824/bytewise-reading-of-memory-signed-char-vs-unsigned-char – Arsenii Fomin Nov 30 '12 at 08:00
  • 2
    @chris: Signed overflow causes undefined behavior only for arithmetic operations. Assignment/initialization (i.e. overflowing signed integral conversions) do not produce undefined behavior. Instead they produce implementation-defined results. – AnT stands with Russia Nov 30 '12 at 08:00

1 Answers1

2

In general case it is not correct to say that the pattern is the same, if the range of signed char does not cover 240. If 240 is out of range, the result of this overflowing initialization is implementation-defined (and may result in a signal, see 6.3.1.3/3). The same applies to char initialization if it is signed.

The language guarantees matching representations only for the common part of the ranges of signed char and unsigned char. E.g. this is guaranteed to produce the same pattern

char c = 10;
unsigned char c = 10;
signed char c = 10;

With 240 there's no such guarantee in general case (assuming it is out of range).

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • 1
    Just wondering, where does the standard mention what happens with `signed char c = 240;`? – chris Nov 30 '12 at 07:59
  • @chris: In `6.3 Conversions -> 6.3.1.3 Signed and unsigned integers`: `6.3.1.3/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. – AnT stands with Russia Nov 30 '12 at 08:02
  • Thanks, I still can't seem to find anything about it in the C++11 standard :/ It seems the whole part you posted was nuked or completely reworded. – chris Nov 30 '12 at 08:06
  • @chris: Oh, I was actually referring to C standard (C99). In C++11 that would be 4.7/3 – AnT stands with Russia Nov 30 '12 at 08:08
  • Although I am sure you are right for all practical purposes, looking at §3.9/4 and §3.9.1/1 (C++11), I wonder: a) While the OP uses the word _object representation_, isn't what we need to find out about the _value representation_? b) Does the Standard really guarantee that the value representation is the same for char/signed char/unsigned char? Btw I think the C99 quotes from the comment above should be part of the answer as well. – jogojapan Nov 30 '12 at 08:11
  • Oh, that makes more sense than me jumping to a C++03 standard conclusion. I didn't realize the question was dually-tagged. – chris Nov 30 '12 at 08:12