Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undefined behavior in C is a reading error

yodaiken.com

Post reply on HN
Print view View original

431–440 of 503 posts

Re: Undefined behavior in C is a reading error

#431

Post by pjmlp »

bigcheesegs wrote: post #290
dooglius wrote: post #122

Earlier quoted context omitted.

The caricatures are somewhat accurate though, optimizations that look at UB adversarially are never anywhere close to justified. > The set of people doing so overlaps with the set of people complaining that the compiler doesn't optimize their code sufficiently to a significant degree. There's no contradiction here, and the overlap is generally just "people who care". The optimizations that are not safe shouldn't exis…

Compiler dev here. Do you really think we just come up with code transformations and add them to the compiler just because? All code transformations have a compile time cost and runtime perf impact. We don't add transformations unless the runtime perf impact greatly outweighs the compile time cost. These optimizations are added because they measurably improve the performance of real code. This comes up in every revie…

However Fortran, Ada, Java, .NET Native, Swift,... are certainly less subject to such optimizations with surprises.

Re: Undefined behavior in C is a reading error

#432

Post by vyodaiken »

Rusky wrote: post #269
vyodaiken wrote: post #237

Earlier quoted context omitted.

The net result of your argument is the language has no semantics. I write and test with -O0 and show that f(k)=m. Then I run with -O3 and f(k)=random. Am I required to be an expert on C Standard and compiler development in order to know that, with no warning, my code has always been wrong? What about if f(k)=m under Gcc 10, but now under Gcc 10.1 that whole section of code is skipped? What you are asking programmers…

> What you are asking programmers to do is to both master the fine points of UB (which is impractical) and look into the future to see what changes may be invisibly committed to the compiler code. I am asking programmers to understand and avoid UB, but I am not asking them to look into the future. Future compilers will still implement the same semantics- that's, again, the point of having a spec! I don't disagree tha…

What indicates the the current semantics won't change next week? After all, it is completely up to the compiler, no?

Re: Undefined behavior in C is a reading error

#433

Post by vyodaiken »

gpderetta wrote: post #406
vyodaiken wrote: post #393

Earlier quoted context omitted.

Linux clone, pthreads, and os code commonly look at stack boundaries

Not sure what you are referring to with stack boundaries. Of course the ABI imposes some minimal requirements at ABI visible points, but these days you can't even rely on the existence of frame pointers to traverse the stack and you have to use the DWARF unwind machinery. And the content of the stack frame itself is completely unspecified of course.

So I create a thread with a custom stack which is an allocated buffer. At the top, I write a sequence of bytes in some order. Then I periodically read the top of the stack to see if the stack is getting close to overflow. Meanwhile, the thread code is also addressing the same store.

Re: Undefined behavior in C is a reading error

#434

Post by aw1621107 »

vyodaiken wrote: post #416
aw1621107 wrote: post #277

Earlier quoted context omitted.

> The obvious intention is that the compiler ignores overflow and lets the processor architecture make the decision. If that were the case, wouldn't signed overflow be implementation-defined or unspecified behavior, instead of undefined behavior? > Assuming that overflow doesn't happen is assuming something false. It's "false" in the same way that assuming two restrict pointers don't alias is "false". It may not be u…

I think the author of that blog was correct: the preferred path is for the compiler to provide data to the programmer to simplify the loop. For your godbolt example, use the C compiler not c++

> I think the author of that blog was correct: the preferred path is for the compiler to provide data to the programmer to simplify the loop.

Requiring the equivalent of PGO is a rather unfortunate bar, though to be fair if you're that interested in performance it's probably something worth looking into anyways.

I'm curious how how noisy an always-on warning for undersized loop variables would be, or how much code would have broken if int were changed to 64 bits on 64-bit platforms...

> For your godbolt example, use the C compiler not c++

Sorry; that was a mistake on my end. The same phenomenon occurs when compiling in C mode, in any case [0].

[0]: https://godbolt.org/z/TvYrzncsc

Re: Undefined behavior in C is a reading error

#435

Post by aw1621107 »

a1369209993 wrote: post #335
aw1621107 wrote: post #331

Earlier quoted context omitted.

> the processor architecture might decide to trap or not trap depending the run-time values of configuration registers that the compiler doesn't know and can't control I'm not certain that that would fall outside implementation-defined behavior. Would something like "Program behavior on overflow is determined by processor model and configuration" not work? > or document. And even if the behavior couldn't be documente…

> Would something like "Program behavior on overflow is determined by processor model and configuration" not work? Not sure; if nothing else, that seems like it would allow the implementation to avoid documenting any implementation-defined behaviour with a blanket "all implementation-defined behaviour is whatever the hardware happens to do when executing the relevant code".

I mean, that works? It's not great by any means, but it at least eliminates the ability to make the assumptions underlying more aggressive optimizations, which seems like it'd address one of the bigger concerns around said optimizations.

Re: Undefined behavior in C is a reading error

#436

Post by tom_mellior »

leosarev wrote: post #420
junke wrote: post #371

Earlier quoted context omitted.

What is the meaning of use(*p) in case p is null? what should the compiler emit?

If p is statically null, it should emit compile time error. If not, it should emit machine instruction to deference p.

In all of the examples above it will emit a machine instruction to dereference p. What your grandparent is complaining about is that it will later remove an "if (!p)" test.

Re: Undefined behavior in C is a reading error

#437

Post by anarazel »

hnjst wrote: post #312
andreareina wrote: post #304

Earlier quoted context omitted.

Isn't checking for overflow depending on UB? i.e. in int a; // lots of code int b = a + 1; // check for overflow if (b the compiler is allowed to remove the check because in the absence of UB a + 1 > a, therefore the conditional is always false.

As brilliantly said further in this thread by someone else, maybe check that something is OK before doing it. In that case, something like: [...] if (a > INT_MAX - 1) abort(); int b = a + 1; [...]

> As brilliantly said further in this thread by someone else, maybe check that something is OK before doing it.

Much easier said than done:

https://github.com/postgres/postgres/blob/master/src/include...

Re: Undefined behavior in C is a reading error

#438

Post by vyodaiken »

msbarnett wrote: post #377
vyodaiken wrote: post #325

Earlier quoted context omitted.

Sure, if you leave out error checks code runs faster. Compile mutexes to no-ops and get an even better speedup.

The optimizations impacted by -fwrapv have nothing whatsoever to do with “leaving out error checks”

I don't know how you can say that

z = x+y; if(zfor(i=start, i >= start && i < n; i++)docomputation(x[i]); etc.

Re: Undefined behavior in C is a reading error

#440

Post by vyodaiken »

steveklabnik wrote: post #87
mjburgess wrote: post #54

Commenters here seem to be missing the core thesis of this article. It's not about what the standard literally means; it's about it's spirit -- and the reason for its spirit. The issue is "undefined behaviour" should never have been interpreted this extremely. The standard may be silent on how extreme, but it is implausible to suggest that the standard was actually written to enable this. Compiler writers for C! dism…

Personally, I think that arguing that those who define and implement a standard don’t understand one of the most fundamental aspects of said standard is going to be an uphill battle. You could argue that they’ve lost their way, and the article flirts with this, but the path forward is the hard part, and IMHO rings a bit hollow: it’s asserted that these rules aren’t needed for performance, but no evidence is given, an…

Wang et al tried this an experiment and found no serious wins.
Post reply on HN