News for hackers. Stuff that matters.

A comment on Defining the Undefinedness of C (2015) [pdf]. Parent comment

Re:Defining the Undefinedness of C (2015) [pdf] by bbatha on Wednesday July 26, 2017 @12:24PM (#14857630)
I've never really understood why this couldn't be slotted in as "implementation defined behavior". `add` has a well defined meaning on every platform just because it differs shouldn't give the compiler license to change the meaning of my program for that platform. It should however platform specific optimizations based on overflow, etc.

Could somebody provide me with an example of truly undefinable behavior? (Perhaps data races?)

[ Parent | on HN ]
Re:Defining the Undefinedness of C (2015) [pdf] by tom_mellior on Wednesday July 26, 2017 @03:32PM (#14859399)
> truly undefinable behavior

Memory corruption is pretty undefinable. Imagine writing data through a wild pointer. The program might segfault immediately, or compute a wrong result but not crash, or crash at an arbitrary later point, or delete all your files, or...

It makes no sense to try to enumerate all that might happen, so this cannot really be implementation defined (where the implementation must document what will happen).

[ Parent | on HN ]
Re:Defining the Undefinedness of C (2015) [pdf] by adrianratnapala on Thursday July 27, 2017 @12:49AM (#14862786)
Right, but it is not the plus operation that does this. You can reserve undefined behaviour to things like "write to a bad pointer".

Then a particular ABI could say "if your pointer overflows (by a our system specific meaning of overlow) then you have a bad pointer". Merely doing a pointer increment just gets you implementation-defined behaviour. The UB only happens if you plough on.

Such a setup wouldn't do much to save us from pointer bugs. But it would make optimizers more predictable.

[ Parent | on HN ]
Re:Defining the Undefinedness of C (2015) [pdf] by jcranmer on Wednesday July 26, 2017 @12:42PM (#14857795)
When C was first written, it wasn't necessarily possible on some architectures to get traps to trigger at the exact instruction on some hardware. Thus, any potentially-trapping instruction had to be undefined instead of implementation-defined.
[ Parent | on HN ]