Reducing undefined behavior in the C language

Reducing undefined behavior in the C language lwn.net

As a professor of biomedical engineering, Martin Uecker perhaps does not fit the profile of a t [...]

47 points•chmaynard•2 days ago•13 comments•

#undefined #behavior #reducing #undefined behavior #reducing undefined #reducing undefined behavior #biomedical #professor

13 comments

kazinator2 days ago

> The question here is: can the compiler hoist the final division operation above assignment to x?

A division calculation not a visible effect. Therefore the question doesn't even m ake sense: it's asking: can we see something that is not a visible effect (division) before or after a visible effect (modification of a volatile object).

uecker2 days ago

But a division that traps because you divide by zero would prevent previous observable behavior from happening when hoisted above it. So it is not about the division itself but about the indirect effect on other behavior that can be observed.

Compilers already understand this: For example, they would not hoist a potentially trapping operation such as a division above a function call. The issue is that they did not apply this rule also to volatile accesses, but LLVM now does because this was fixed.

kazinator2 days ago

but "previous observable behavior" just means whatever actually happened, not that it was required to be previous.

wahern2 days ago

What if x is a register to toggle divide-by-zero exceptions? Normally this is none of the compilers business, but the whole point of volatile is a mechanism to express stuff like that, so it needs minimal semantics, e.g. no time traveling (compiler barrier), to be fit for purpose.

kazinator2 days ago

x being a register connected to the processor's division machinery doesn't speak to the fact that division isn't a language-defined visible effect, and so the implementation is not required to schedule it in a certain way in relation to the store to x.

codedokode2 days ago

I wish they added some simple form of generics so that one could, for example, create types like "list of files", "list of processes" without duplicating the code.

Also, something for RAII, so that one could automatically deallocate allocated memory.

Someone2 days ago

How does that help reduce undefined behavior in C?

Also:

- for ‘generics’: X macros (https://en.wikipedia.org/wiki/X_macro, if desired in combination with _Generic (https://en.cppreference.com/c/language/generic), or use C++, if desired with linting that rejects use of some features.

- for RAII: I think ‘defer’ is in the pipeline. Not quite the same, but useful anyways. gcc and clang already support it (with not-so-nice syntax; see https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Variable..., look for cleanup)

childintime2 days ago

I thought this would be about adding a switch by which to undo every silent code removal operation because the compiler concluded a section includes undefined behavior in some obscure case, like overflow. And doing so silently. So when you recompile on a new compiler, on embedded, your code now fails. Can't do that Dave.

How did we ever get here??

As a user that's so outrageous it must be a deliberate conspiracy against C. I'm sure it isn't but it certainly helps it's demise, as the feeling the tool is in the hands of imbeciles that mistake the trees for he forest. C now requires you to be an expert on undefined behavior, and the psychology regarding the matter, while previously C would be forgiving.

So I thought the article would be about --forgive --generous, or --embedded while there should have been --petty in the first place.

fuhsnn2 days ago

Isn't UBsan such a switch?

Read the full thread on Hacker News →

13 comments

Related stories