0

In a book on C++ Programming, a question was: "An int variable x is initialised with the value 92,126. What will be the result when this is run on an MS-DOS compiler? "

The answer said since x=92126 is larger than the maximum value an int variable can store (namely, 32,767) on an MS-DOS compiler, so x will be mangled and the output would be 26,590.

I don't understand what "mangling" is. I couldn't find anything about it on the net. So, I don't know why the result is 26,590. I think, if anything, since the maximum value possible is 32,767, that should be the result. But I am not sure. I need some help on this.

Here's the link for the chapter of the book containing the problem (question 4.1) and its solution: https://www.safaribooksonline.com/library/view/practical-c-programming/0596004192/ch04.html

  • The term "mangling" is wrong. What happens with *signed* integer overflow is technically [*undefined behavior*](https://en.wikipedia.org/wiki/Undefined_behavior), but in reality what usually happens is either a modulo operation or the top-bits are just cut of and the value is truncated. – Some programmer dude Jul 30 '18 at 11:26
  • 1
    @Someprogrammerdude It's not UB in initialization iirc, just yields an implementation defined value. – Baum mit Augen Jul 30 '18 at 11:29
  • @BaummitAugen True, wrong of me. It's "only" *implementation defined* (according to [this integral conversion reference](https://en.cppreference.com/w/cpp/language/implicit_conversion#Integral_conversions)). – Some programmer dude Jul 30 '18 at 11:33
  • @Someprogrammerdude, Can you clarify what are "top-bits"? Are they the most significant bits? Because after seeing your reply, I cancelled out the MSB (viz. 65536) from 92126 and the result was 26590! – HeWhoMustBeNamed Jul 30 '18 at 11:35
  • Yes, I mean the most significant bits. All but the low 16 bits could simply by disregarded. – Some programmer dude Jul 30 '18 at 11:36
  • @Someprogrammerdude, thanks for this! I think this answers the question. :-) – HeWhoMustBeNamed Jul 30 '18 at 11:39

1 Answers1

-1

Ditch the book.

There's no good answer. From a C++ perspective, "purple" is a valid outcome. The relevant term is not "mangled", it's Undefined Behavior. Literally anything can happen. There's certainly no restriction that x holds a numerical value, or even that x exists afterwards.

The reason that this is Undefined Behavior is because it's signed integer overflow. unsigned int x = 92,126UL would be a different matter, that's unambiguously 26590 when the target system has 16 bits integers (like MS-DOS did)

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • It is not undefined behavior, it yields an implementation defined result. Given they stated what implementation they are talking about (more or less, granted), the question is not even *that* unreasonable (though useless). – Baum mit Augen Jul 30 '18 at 14:13
  • @BaummitAugen: Proposal p0907r0 postdates C++17, and isn't accepted anyway - right? AFAICT from C++'98 to C++' 17, all standards have left signed integer overflow undefined. For the downvoter: https://stackoverflow.com/questions/16188263/is-signed-integer-overflow-still-undefined-behavior-in-c – MSalters Jul 30 '18 at 16:36
  • 1
    This isn't an example of signed overflow though because we are not doing arithmetic. For conversions, *"If the destination type is signed, the value is unchanged if it can be represented in the destination type; otherwise, the value is implementation-defined."* (7.8/3 in N4659) applies. – Baum mit Augen Jul 30 '18 at 16:40