An 'interesting' thing you can do in C++

[MK14]

I've tried out of curiosity and using int* i= malloc(sizeof(int)); and *i everywhere instead of i, it always gives 0 no matter what, with gcc in Intel and ARM.

I tried it (Malloc and * etc, I changed the syntax a bit, so it supports C and C++) using the online GCC, and it came up with the same values as before (i.e. made no difference). But I'm not sure if the online GCC, uses strange memory models (i.e. they hacked/changed it, or it doesn't use the stack/heap system, etc etc), so that it can run using little/limited server resources.
So doing it on a real machine (I can well believe), could give different results.
The problem if I do it on my machine, is I can't directly share the results on the forum, for others to mess/experiment with it. Because we are probably running different OS versions, different GCC's etc.

https://onlinegdb.com/SJz0RMjO7

[brucehoult]

I've noticed an annoying trend.
In the old days, if you used an ambiguous syntax that the spec claimed was "undefined", you would tend to get a result that made sense, more or less.  It might not be the same on all systems and all compilers, but each result would be ... sensible, looked at from some perspective.
More recently, less so.  The compiler developers mumble about optimization and etc, but I think they're doing it out of spite.
Some of the cases are particularly annoying to embedded developers.I've run into situation where common constructs no longer work as expected:

Code: [Select]

uint8_t time = 0 - delaytime;while (++time != 0) {    //stuff.}"The behavior of C WRT integer overflow is undefined.  The compiler decided that incrementing a non-zero value would never reach 0, and made the loop unconditional and infinite."

Code: [Select]

   while (1);   // stop the program"A while loop may be assumed to terminate.  Since the loop is empty and doesn't do anything, the code was entirely omitted."
https://stackoverflow.com/questions/16436237/is-while1-undefined-behavior-in-c

Grr.

Those are pretty rubbish ways to do things, especially assuming processor speed (MHz and IPC) to get a delay. Much better to use a cycle count register. Alas some simpler MCUs don't have one. RISC-V *requires* all implementations to have a 32 bit cycle counter.

However, if you insist on coding that way, popping a 'asm volatile ("")' inside your loop will convince gcc at least to never optimise it away.

[newbrain]

However, if you insist on coding that way, popping a 'asm volatile ("")' inside your loop will convince gcc at least to never optimise it away.

But do gcc or other compilers really optimise this things away?
In my reading of the standard this would definitely be non-conforming, have I overlooked something?

In the first case, if there are actually no statements with side effects inside the while ( "// stuff" ), the compiler could just assign 0 to delay and be done with that (since it's not been declared volatile), but cannot simply omit the loop, as its controlling expression has a visible side effect.

The second case is a bit hairier, but still it's not UB, and as such should be honoured. The compiler cannot assume it terminates and remove it as it has no side effects.

[SiliconWizard]

The second case is a bit hairier, but still it's not UB, and as such should be honoured. The compiler cannot assume it terminates and remove it as it has no side effects.

An infinite loop such as

Code: [Select]

while (1) ; should obviously not be optimized away as it has a clear an unambiguous effect: halting the execution.