Hacker News Reader

Comment by jasonhansel | Hacker News Reader

I really think that we need a standard variant of C in which all undefined behavior is (somehow, even if arbitrarily) defined. (Also: a variant with some restricted level of polymorphism would make C much less painful.)

View on HN

That's not possible in general, for instance if you write a block of memory than execute it, you can't really define what's going to happen without including an ISA in your language spec. Another example would be executing a syscall with a not-yet-used number. The ability to do both of these things are necessary for a low-level language such as C.

you can't really define what's going to happen without including an ISA in your language spec.

That's called "implementation-defined".

True, but there are a lot of things that are also undefined at the ISA level

Don't specify that at all in the standard. Let compilers implement it as an extension, like inline asm. They'll have to make it have sane behaviour because they don't have the excuse of 'the standard says it's ub'.

The standard actually has a definition of the range of permissible behavior for UB:

Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

However, an update to the standard made this definition non-binding. It is still in the standard, verbatim, but compiler writers have interpreted that to mean they can completely ignore it and build compilers whose behavior goes way outside the "permissible" range.

See https://blog.metaobject.com/2018/07/a-one-word-change-to-c-s...

You seem to be saying that the meaning of this clause in the standards is undefined (or is it implementation-defined?)

I have no idea what the authors of the standard would have in mind in putting a non-binding constraint in a standard, unless there's a faction that hopes to make it binding in the future, and hopes this will pave the way.

It used to be binding, was later changed to be non-binding.

Somewhat related, does anybody here know what compiler flags to use to get "friendly C" (aka do-what-I-mean, or high-level assembler)? I want it to do the "obvious" thing in case of UB, for example dereferencing a pointer will just simply read the memory at that address.

(I can live without the optimizations, as most code I write is bounded by algorithmic complexity, IO, or not performance sensitive. If I find it neccessary, I'd tune the options for a specific piece of code.)

I know about: -fno-delete-null-pointer-checks -fno-strict-aliasing -fwrapv

Are there any other such options?

This is unlikely to happen because of the performance penalty it would incur (e.g. defining outcome of all out-of-bound memory accesses).

I would expect that it would still be faster and use less memory than most of the other popular languages today (e.g., C#, Python, or JavaScript).

It would be just another option to choose from. Solving some of those undefined behaviors may even provide other benefits (e.g., better compiler error messages, optimizations, or portability).

Reply on news.ycombinator.com