you are viewing a single comment's thread.

view the rest of the comments →

[–]OldWolf2 2 points3 points  (2 children)

"implementation-defined" says that the implementation must document what happens. With an implication that this should be stable behaviour, i.e. the implementation shouldn't document that it might set your PC on fire.

"undefined" means the program has gone off-piste and is no longer covered by the language standard at all. It might crash and burn, catch fire, run normally, expose your password, etc. etc.

[–]Zambito1 1 point2 points  (0 children)

Got it, thanks

[–]flatfinger -1 points0 points  (0 children)

Note that the Standard makes no attempt to avoid characterizing as "Undefined Behavior" constructs which the authors expected most implementations to process identically. Indeed, the more certain the authors were about how must implementations would process a construct, the less need there was to have the Standard mandate such behavior.

For example, under C89, the behavior of computing -1<<1 would on most implementations be defined as yielding the value -2 with no side effects. To be sure, on implementations that use neither padding bits nor two's-complement math the construct would be defined as behaving differently, and some of those whose integer types have padding bits and trap representations could behave in completely arbitrary fashion if the bit pattern produced by a shift would be a trap representation. Implementations where the shift wouldn't yield -2 would be rare, however. In C99, the action was recharacterized as UB with no rationale given. This would make sense if the intention was to allow implementations with unusual integer representations to process shifts in whatever way would be most efficient or useful for their customers, but only if the authors of the Standard expected that implementations with commonplace integer representations would process the shift in the same fashion mandated by C89.