The first two invoke UB and are thus completely illogical.
No they don't. What UB do you think they invoke?
They do invoke implementation defined behaviour, but not undefined.
Who Says C is Simple? (2010)
11–20 of 59 posts
Re: Who Says C is Simple? (2010)
#12The first two invoke UB and are thus completely illogical.
The example is written in a strange way. You're supposed to assume x is initialized ("for most values of x").
I think it's just pointing out the difference between '&' and '&&'.
Re: Who Says C is Simple? (2010)
#13Re: Who Says C is Simple? (2010)
#14Re: Who Says C is Simple? (2010)
#15The first two invoke UB and are thus completely illogical.
The first invokes UB if you assume that x is a local variable, and the second doesn't at all as far as I can tell. Care to explain?
To elaborate, the second expression has an underflow at 1 - sizeof(int) on an unsigned integer (promotion due to sizeof being unsigned), which is perfectly well defined:
"if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type."
The right shift is fine on a signed or unsigned integer. For the unsigned case (which is this one due to operator precedence), the behavior is well defined. For signed, implementation defined.
EDIT: The right shift is in fact UB assuming sizeof(int) <= 4.
Re: Who Says C is Simple? (2010)
#16Re: Who Says C is Simple? (2010)
#17who said C is simple? :S
C is simple, but that doesn't mean it's not powerful, and with power comes... yada yada yada. There are many edge cases to be sure, but as a language, its constructs and features are very simple.
Re: Who Says C is Simple? (2010)
#18The first two invoke UB and are thus completely illogical.
The first invokes UB if you assume that x is a local variable, and the second doesn't at all as far as I can tell. Care to explain? To elaborate, the second expression has an underflow at 1 - sizeof(int) on an unsigned integer (promotion due to sizeof being unsigned), which is perfectly well defined: "if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum val…
The behavior is only well defined if the shift amount is strictly less than the width of the operand. If `size_t` is 32 bits, then shifting right by 32 bits is undefined.
I know of three different ways in which platforms implement shifts by greater than the word size.
Re: Who Says C is Simple? (2010)
#19Who says simple things always yield simple results?
Re: Who Says C is Simple? (2010)
#20C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.)
That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code; it didn't take much to get inside the head of a C compiler, so you could be reasonably sure that a simple piece of C would result in a similarly simple piece of assembly out the other end.
That, of course, was well and good when it was reasonably simple to predict actual performance from glancing at assembly code, which assumes opcode performance (as opposed to, say, cache performance) dominates how fast the code runs.
Now... how many of those things still hold true on desktop and server class hardware?