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

101–110 of 503 posts

Re: Undefined behavior in C is a reading error

#101

Post by anarazel »

_kst_ wrote: post #94
anarazel wrote: post #45

Earlier quoted context omitted.

> For example, if signed integer overflow yielded an unspecified result rather than causing undefined behavior, I wonder if any implementations would be adversely affected. I suspect so - makes it harder to reason about loop counts because the compiler can't necessarily guarantee that an incremented loop counter won't become negative and thus the loop needs to iterate more. E.g. something like for (int i=param; i Tha…

for (int i=param; i does not have a guaranteed loop count with the current rules. The loop body will execute 16 times if param <= INT_MAX-16, but if the expression "param + 16" can overflow, the behavior is undefined. (I'm assuming param is of type int.)

That's precisely my point? Because the overflow case is undefined, the compiler can assume it doesn't happen and optimize based on the fixed loop count.

Re: Undefined behavior in C is a reading error

#102

Post by rectang »

anarazel wrote: post #76

First: I do dislike how hard it is to avoid some UB / how impractical some of the rules are. But I also think a lot of discussions of this topic caricaturize compiler writers to a ridiculous degree. Almost describing them to write optimization passes looking for UB so they can over-optimize something, while cackling loudly in glee about all the programs they can break. The set of people doing so overlaps with the set…

> But I also think a lot of discussions of this topic caricaturize compiler writers to a ridiculous degree.

The inflamed backlash should tell you just how damaging it is to impose silent failure on meticulously written, previously fine programs.

Re: Undefined behavior in C is a reading error

#103

Post by coliveira »

kmeisthax wrote: post #9
goalieca wrote: post #3

If C is just a portable assembler then what if the assembly itself has undefined behaviour. :)

This exists, but the effect of undefined behavior in CPU architectures is a little bit more forgiving than the interpretation of UB in C to mean "literally the entire program has no meaning". Instead, usually the program will execute correctly up to the invalid instruction, and then something happens, and then the CPU will continue executing from that state. It's actually fairly difficult to build an instruction with…

The situation is different, because a CPU is by definition an interpreter. It does't perform code transformation, at least not at a higher level as a compiler. The CPU only looks at the next few instructions and perform them. A compiler, however, is responsible for taking a large coding unit and produce a transformation that is efficient. That process requires thinking about what is invalid code and operate on that.

Re: Undefined behavior in C is a reading error

#105

Post by coliveira »

infogulch wrote: post #29
mhh__ wrote: post #18

Earlier quoted context omitted.

Skimmed the article and didn't see a reference to it, you may be interested to know that our good friends and protectors at the NSA may have stumbled on to Meltdown-like issues in the mid 90s https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...

I see the NSA strategy for 'securing' the nation against technology threats in their 'unique' way was going strong back in 1995.

They "secure" the country by exploiting vulnerabilities and leaving everyone else in the dark. They see the world as just a game between them and other foreign surveillance institutions.

Re: Undefined behavior in C is a reading error

#106

Post by DangitBobby »

It truly boggles my mind that this discussion (linked in TFA) played out the way it did. In my mind it's 100% not okay to (by default) optimize away a check for integer overflow. I've never really written in C (or any unsafe language) before so I had little context for the types of traps C sets for developers. Based on the responses of the person who presumably implemented the optimization, it comes as no surprise that C is so dangerous. After reading this I hope I never have to use gcc.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475

Re: Undefined behavior in C is a reading error

#107

Post by olliej »

I dislike how UB is used where unspecified would work.

For instance overflowing arithmetic is well specified on every architecture - the behaviour may be different on say sparc vs an hc12 vs x86, but on any of those architectures it will always be the same. Yet compiler devs have instead decided that it is undefined and so can be treated however they like.

There are so many of these UB that could be unspecified that it’s absurd - UB should be reserved for when there outcome is not consistent - UaF, invalid pointers, out of range accesses, etc

Re: Undefined behavior in C is a reading error

#108

Post by Jiro »

richardwhiuk wrote: post #88
Jiro wrote: post #77

Earlier quoted context omitted.

>Somehow the author seems to think that this is not what the wording intended, but they also fail to explain what they think should happen here. What "should" happen is that the implementation-defined behavior in the assert matches the implementation-defined behavior in the calculation. That is, assert(a+100>a) should produce the same result as int x = a + 100; int y = a; if (x > y) ; else printf("assertion failed\n"…

That behaviour is no less undefined in the process of overflow.

Okay, then let's rephrase without a code example: The implementation-defined behavior in the assert should produce "true" if and only if the number printed for x+100 (also using implementation-defined behavior) is always larger than the number printed for x.

Re: Undefined behavior in C is a reading error

#109

Post by optymizer »

anarazel wrote: post #80
optymizer wrote: post #70

Earlier quoted context omitted.

Anecdotally, I find about as many bugs in my Java code at work, as I do in my hobby C code, including "dereferencing null pointers" aka NullPointerExceptions.

NPE isn't really a relevant comparison point - it raises an exception of sorts in both languages. Accessing an array past its end, accessing freed memory, reading uninitialized memory seem more apt.

These are all issues a compiler could insert checks for, saving you the time to do it manually, while trading performance for security or correctness.

C doesn't trade performance away, so if you'd like to pay the price of these checks, it's on you, the programmer to add them in. C programmers have to put in extra effort to make the executables safer and output correct results.

Other languages trade off performance for safety and/or correctness. The programmers using them have to put in extra effort to make the executables run as fast as they do in C.

Ultimately, programmers tend to make rational choices, and the stockholm syndrome mentioned above is really just C programmers dealing with the consequences of the trade-off they made by using C.

Re: Undefined behavior in C is a reading error

#110

Post by anarazel »

zokier wrote: post #89

Reading error or not, the ship has sailed long ago. As the article notes, C99 formalized the current UB interpretation. What C89 or K&R said is more just historical curiosity than of any real relevance today. I guess you could construct an argument that gcc should disable some optimizations when invoked with -std=c89, but I doubt anyone really cares at this point enough to justify the maintenance burden. C is a minef…

> C is a minefield today, and that is the reality we must live with. You can't turn back time 25 years and change what has happened.

I think it's doable to make some of the UB issues considerably less painful. E.g. define facilities to check for overflow safely, add facilities for explicit wrapping operations.

Post reply on HN