What is the difference between debug and release, of a project

[AKuma.2074]

Hi,

I am completely new into microcontrollers. And while working with keil as well as smt32cube ide i found options such as debug and release.

Can someone please tell me whats the difference between both, what benefit one has on other and when to use when.

Thanks and regards

[Tesla DeLorean]

TBH if you have to single step your own code to understand how it works you're already in serious trouble.

[CTapp.1]

It "breaks" because it contains undefined-behaviour (there is no return statement on an exit path from a function having non-void return type. The default is also unreachable, and that adds further to the "unexpected" code generation.

[waclawek.jan]

Oh, it's C++, not C.

Language matters, too.

JW

[CTapp.1]

Yeah, it can make a difference (and does in that case) - the compilers (and optimisers) are not the same.

For example, the unreachable code has no effect when the example is compiled as C using GCC, but it does when compiling under Clang (the default is optimised out).

[waclawek.jan]

> For example, the unreachable code has no effect when the example is compiled as C using GCC, but it does when compiling under Clang (the default is optimised out).

There is no unreachable code in C, enum specifiers (i.e. the type generated from the enum, not the individual enum symbols/constants) are compatible with int (more precisely, with some of char, signed integer or unsigned integer type, by compiler's choice, C99 6.7.2.2#4), so they can take any value within that type, not just the enumerated values (C99 6.3#2, "Conversion of an operand value to a compatible type causes no change to the value or the representation.")

This is one of the many minor but important differences between C and C++ (the other in this example is treatment of no-return-from-function-with-non-void-return-type).

I wonder what were the conditions under which Clang optimized out the default.

I tried in goldbolt, and indeed, Clang set to C removes that branch with -O2 even with -fno-strict-enums. IMO that's a flaw and I'd like to hear the author's rationale for this.

JW

[CTapp.1]

Whilst it is true that an enum object can take any int value, the default is unreachable as the branch to it is infeasible. The compiler can "see" that the only values assigned to state are S0 and S1, and the compiler is allowed (using the "as-if principle) to use that during optimisation.

The only means by which state could hold a different value is by memory corruption, but that is not within the scope of the abstract machine that is used during code generation and it therefore does not have to be considered.

[waclawek.jan]

Oh.

Now I see.

I've seen

static T state = 50;

which would indeed some sort of violation in C++ and perfectly OK in C.

::blushing::

Sorry for the confusion.

Your explanation is then perfectly valid and yes, the default branch can be optimized out, together with the error() call and, consequently, if there's nothing else to call error(), that function can be eliminated too.

In fact, as state is static (i.e. not visible outside f()), and there are no side effects (as it's not volatile), both this variable and thus the whole f() function can be optimized out.

JW