3

My curiosity got the better of me. What would happen (or does happen) when you write the code:

char pseudo_char = 256;

Would it store a virtual char with a value of 256? Or is this illegal and should never be done?

C_B
  • 2,620
  • 3
  • 23
  • 45

3 Answers3

9

It's probably an overflow (unless CHAR_MAX >= 256). That's Undefined Behavior, and anything may happen. It's unlikely to format your harddisk.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • 4
    `It's unlikely to format your harddisk.` I like that remark. – Bart van Nierop Mar 31 '14 at 09:33
  • Interesting. And should CHAR_MAX ever be >=256? I would assume not. – C_B Mar 31 '14 at 09:38
  • @C_B: I'd expect it to be 32767 or 65535 when `CHAR_BIT==16`. – MSalters Mar 31 '14 at 09:40
  • @C_B Some icky compilers use `char` as 16 bits when implementing a larger symbol table, instead of using `wchar_t` for such things. – Lundin Mar 31 '14 at 09:42
  • @Lundin: That's rarely the reason. `char` is the smallest addressable object (i.e. sizeof(char)==1). On some DSPs, it's impossible to address 8 bits. – MSalters Mar 31 '14 at 09:46
  • @MSalters Does the C standard actually mandate that char is the smallest addressable object? – Lundin Mar 31 '14 at 09:50
  • @Lundin: Yes. Else you could create a pointer that you couldn't cast to `char*`, and that would e.g.. break `memcpy`. – MSalters Mar 31 '14 at 09:51
  • @MSalters I believe that casting to and from char* is implementation-defined behavior, so if someone wanted to make some really weird implementation, there's probably room for it. I don't think there exists any text anywhere in the standard that mandates that a certain pointer type must be able to point at the smallest addressable object. I'm not sure, so if you are, please point of the relevant section of the standard. – Lundin Mar 31 '14 at 10:01
  • @Lundin: See http://stackoverflow.com/questions/13995748/when-and-how-is-conversion-to-char-pointer-allowed for all details including relevant sections. – MSalters Mar 31 '14 at 10:17
1

This would be an undefined behavior. The range of char is -128 to +127 or 0 to 255 based on if it is signed or unsigned, so anything may happen in your case.

Would it store a virtual char with a value of 256?

It will show you an undefined behavior. Something which you cant predict.

Or is this illegal and should never be done?

I would not say that it is illegal but yes if you dont want to get into unpredictable environment then dont do this.

Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331
1

That would produce a warning saying "overflow occured". But I figured out that after 255 any other number assigned to the char - it restarts from 0 and assigns appropriate ASCII char to it. Like 

256 -> (null) equivalent to 0

300 = 256+44 -> , equivalent to 44
Vishal R
  • 1,026
  • 1
  • 7
  • 21
  • Very interesting, nice touch. – C_B Mar 31 '14 at 09:40
  • 3
    Note that this a compiler-specific answer, but fails to state which compiler. And on some compilers it even depends on settings (e.g. in Visual Studio 400->144 OR -112) – MSalters Mar 31 '14 at 09:43
  • I would like to know whether this is machine dependant or something? Is is that LSB is discared by compiler after reaching 255 limit? – Vishal R Mar 31 '14 at 09:45
  • 1
    Most likely the compiler will indeed implement integer overflow like this, but there are no guarantees. Simply because the C standard decided: "Oh no, overflow! Lets panic and make this undefined behavior.". Even though there is actually no reason why they couldn't have made it well-defined. It's related to the retarded way the C standard allows different forms of signed number formats, other than two's complement. – Lundin Mar 31 '14 at 09:47
  • 1
    @Lundin: ANd how would you implement two's complement efficiently on a CPU that does one's complement or has an explicit sign bit. If you think those are theoretical, the Cray supercomputers had sign bits. – MSalters Mar 31 '14 at 09:50
  • @MSalters That's the problem, the C standard is an ISO standard so they aren't allowed to favour certain architectures and thereby give them a market advantage. But if they simply had defined signed numbers to always be two's complement and those obscure, experimental computers be damned, then C would have been a far better programming language. – Lundin Mar 31 '14 at 09:55
  • 1
    @Lundin: nonsense, the C rules predate ISO by about a decade. Also, ISO standards may certainly favor certain architectures. For example, C favors machines with a stack. – MSalters Mar 31 '14 at 10:01
  • @MSalters Well, that's what I heard from someone who was actually on the C99 committee. – Lundin Mar 31 '14 at 10:03
  • @Lundin: You probably misunderstood. I was a member of WG21, not WG14, but they operate under the same ISO rules. Both work on a consensus model, and for that reason generally do not favor specific architectures. It got really complicated with the memory models for multi-threading, where it's trivial to accidentally favor an architecture. – MSalters Mar 31 '14 at 10:10