This changes the semantics for expressions in assert that do have side effects, as the side effects will still trigger with NDEBUG.

However, I think the new behavior is actually convenient in many cases. I will call it assert_ng() and keep an assert() with correct semantics.

A use case for assert_ng(): assert_ng(foo_init() == 0) will still init foo with NDEBUG, just the check will be optimized out.

In a follow up all instances of

void foo(int bar)
{
    (void)bar;
    assert(bar == 42);
}

can be converted to

void foo(int bar)
{
    assert_ng(bar == 42);
}

And all instances of

void foo(void)
{
    int retval = bar_init();
    (void)retval;
    assert(retval == 0);
}

can be converted to

void foo(void)
{
    assert_ng(bar_init() == 0);
}

What does ng stand for? I hope not next-generation, because at least the enforced evaluation of the expression sounds like a downgrade. Also keep in mind, that the POSIX spec actually specifies assert to be a macro, so I don't see much chances that assert is replaced with assert_ng at some point.

I'm also skeptical. assert() may be somewhat ugly, but it is standardized and well understood.

because at least the enforced evaluation of the expression sounds like a downgrade

Well, this is my selling point for it ;-)

Because our CI always compiles without NDEBUG, things start to horribly break all over the place once NDEBUG is defined. Most often it is only an -Wunused starting to trigger, but occasionally it is because the expression in assert() has side effects the program relies upon.

What is the point in having a program showing different observable behavior in absence of failed assertions with and without NDEBUG? (And using more CPU cycles and ROM is not considered observable behavior in terms of the C abstract machine.) IMO, this only shows how little thought has gone into the standard.

I'm also skeptical. assert() may be somewhat ugly, but it is standardized and well understood.

But this provides a second macro with fixed semantics. It is not changing the semantics of assert().

Don't we have expect() for that already?

Don't we have expect() for that already?

expect() is a bit different: it just never compiles out. IIUC this assert_ng() is supposed to just ignore the result when NDEBUG is set.

occasionally it is because the expression in assert() has side effects the program relies upon.

doesn't cppcheck warn on that? Anyhow, I'd rather fix those than use assert_ng().

doesn't cppcheck warn on that?

With --enable=style it indeed does.

Maybe we should consider to just add -Wno-unused-parameter when DEVELHELP is disabled to fix the second issue?

I will drop assert_ng() for now to at least get the ROM reduction and test in.

PR stripped of assert_ng().

Strange. Using my toolchain I get 460 B less for examples/gnrc_networking. Using BUILD_IN_DOCKER, I get 756 B more ROM with this PR :-/

Can you please provide a reason why this was closed? It is not really obvious from the course of discussion here.