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

301–310 of 503 posts

Re: Undefined behavior in C is a reading error

#301

Post by vyodaiken »

msbarnett wrote: post #123
bhk wrote: post #112

Earlier quoted context omitted.

It isn't clear to me precisely what example you have in mind. If you are saying that deleting array bounds checks might have performance benefits that outweigh the security concerns, then I disagree. If you are saying that the compiler would have to insert bounds checks, I don't see how you arrive at that. I have seen claims that gratuitous UB is important for enabling meaningful optimizations, but in every such case…

> If you are saying that deleting array bounds checks might have performance benefits that outweigh the security concerns, then I disagree. I'm saying that there is existing code in this world in which some variation on /* insanely hot loop where ARRAYSIZE > 32 */ while(true) { ... int x = 1 exists that's currently compiling down to just "a[index] = 1 I'm saying that the authors and their customers are unlikely to be…

There is zero customer demand for less reliable code as a tradeoff for "performance"

Re: Undefined behavior in C is a reading error

#302

Post by jchb »

rectang wrote: post #299
layer8 wrote: post #279

Earlier quoted context omitted.

> In particular, nothing in the wording of the standard expliclty says that an implementation is expected to assume UB doesn't happen, or that a standard-conforming program can't have UB. An implementation isn't expected to assume that UB doesn't occur, but it is allowed to assume that. With regard to programs, the C standard has two different notions of conformance (cf. chapter 4 Conformance). There are strictly con…

I despair at writing C code where the compiler won't silently surprise me. How are we supposed to learn all these subtle rules and intuit when to apply them without making any mistakes?

By learning only the most important rules, and then enable the compilers undefined behaviour sanitizer(1) during development, making mistakes, and fixing them.

(1)https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#...

Re: Undefined behavior in C is a reading error

#303

Post by UncleMeat »

lmm wrote: post #297
UncleMeat wrote: post #148

Earlier quoted context omitted.

IMO, implementation defined is worse. It is still a time bomb but now it is a time bomb that you cannot use compiler errors to prevent automatically.

How so? The implementation can, and perhaps should, define that it errors. Whatever behaviour you're worried about a compiler doing for implementation-defined behaviour, it could do exactly the same thing if the behaviour was undefined.

Implementation defined behavior can only ever produce compiler warnings, which you can choose to be commit blockers if you want. But if a compiler can prove that UB can happen then it can completely prevent you from building that program.

Re: Undefined behavior in C is a reading error

#304

Post by andreareina »

jcranmer wrote: post #120
rectang wrote: post #102

Earlier quoted context omitted.

> 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.

> meticulously written, previously fine programs With relatively few exceptions, if your program hits undefined behavior, then your program was already doing something pretty wrong to begin with. Signed overflow is a poignant example: in how many contexts is INT_MAX + 1 overflowing to INT_MIN actually sane semantics? Unless you're immediately attempting to check the result to see if it overflowed (which is extremely…

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.

Re: Undefined behavior in C is a reading error

#305

Post by a1369209993 »

aw1621107 wrote: post #277
vyodaiken wrote: post #241

Earlier quoted context omitted.

More than slightly convoluted. The obvious intention is that the compiler ignores overflow and lets the processor architecture make the decision. Assuming that overflow doesn't happen is assuming something false. There's no excuse for that and it doesn't "optimize" anything.

> 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…

> If that were the case, wouldn't signed overflow be implementation-defined or unspecified behavior, instead of undefined behavior?

No, because (among other reasons) 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 or document.

Re: Undefined behavior in C is a reading error

#306

Post by saagarjha »

a1369209993 wrote: post #298
PeterisP wrote: post #281

Earlier quoted context omitted.

For me, the canonical UB example is a buffer overflow. No matter how you define UB, in practice a buffer overflow can result in for example, a system crash or - given appropriate very specific input data - encrypting all the files on your hard drive for a ransom. Requiring compilers to restrict UB to something similar to unspecified behavior (where the behavior is not specified by the standard, but a C implementation…

> given appropriate very specific input data That's the operative words there. Compilers are not required to ensure that, in sufficiently perverse circumstances, undefined behaviour never results in demons flying out of you nose. They are , however, required to not actively put said demons there themselves, because that's part of what distinguishes a programming language implementation from a piece of malware masquer…

Compilers never actively try to put demons in your program. However, they do occasionally end up making constructs that result from a reasonable (if not the most well-thought-out) chain of decisions that end up looking like demons to the untrained eye.

Re: Undefined behavior in C is a reading error

#307

Post by saagarjha »

alerighi wrote: post #259
bregma wrote: post #211

Earlier quoted context omitted.

from ISO/IEC 9899:2011 "Programming Languages -- C" 3.4.3 1 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner charac…

To me ignore the situation completely with unpredictable results would mean: the compiler generates an assembly that could not be correct, and then the behaviour of the program is determined by what the processor does. Doing something like removing checks is not ignoring the situation: is acting in some particular way when undefined behaviour is detected. And it has neither unpredictable results: it specifies what ha…

This is untenable, because different compilers will generate different sequences of instructions which will misbehave in different ways. For example, one compiler may choose to reorder the actual memory access until much later, to a branch of the code that doesn't execute in some cases, so "the hardware implementation" could vary from "nothing happens" to "consistent SIGSEGV".

Re: Undefined behavior in C is a reading error

#308

Post by nytgop77 »

lixtra wrote: post #185
jcranmer wrote: post #120

Earlier quoted context omitted.

> meticulously written, previously fine programs With relatively few exceptions, if your program hits undefined behavior, then your program was already doing something pretty wrong to begin with. Signed overflow is a poignant example: in how many contexts is INT_MAX + 1 overflowing to INT_MIN actually sane semantics? Unless you're immediately attempting to check the result to see if it overflowed (which is extremely…

> With relatively few exceptions, if your program hits undefined behavior, then your program was already doing something pretty wrong to begin with. The author claims: “We have the absurd situation that C, specifically constructed to write the UNIX kernel, cannot be used to write operating systems. In fact, Linux and other operating systems are written in an unstable dialect of C that is produced by using a number of…

Somewhat similar to sql situation. (difference being, i am not sure if anybody implements ansi-sql fully)

Standard is just common denominator agreed by actual competitors. (Standard takes into account the chipset where incrementing max_int produces a beep instead of min_int). If user wants to use more advantages of the product (dbms/compiler/hardware), one must sacrifice portability and use cnonstandard extensions.

Re: Undefined behavior in C is a reading error

#309

Post by saagarjha »

alerighi wrote: post #263
nwallin wrote: post #249

Earlier quoted context omitted.

> - "Undefined behavior" means that C implementations are allowed to assume that the respective runtime condition does not ever occur, and for example can generate optimized code based on that assumption. Please note that the article is making the specific argument that this interpretation of UB is an incorrect interpretation. The author is arguing that you, me, the llvm and gcc teams are wrong to interpret UB that w…

By the way, dereferencing NULL is a well defined behaviour on every computer architecture: you are basically reading at address 0 of memory. It just causes a crash if you have an operating system since it will cause a page fault, but in kernel mode or in devices without an OS is a legit thing to do (and even useful in some cases). Why should C compilers make it undefined? The standard doesn't mandate that undefined b…

NULL is not required to have a bit representation of all zeroes. If you are programming for a low-level hardware device, it might be worth your while to get a C implementation that does not represent the NULL pointer this way.

Re: Undefined behavior in C is a reading error

#310

Post by a1369209993 »

mjw1007 wrote: post #118
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…

I agree. I don't have much sympathy for people who were doing things like writing multithreaded programs in the days before C documented its memory model and then becoming unhappy because new optimisations that legitimately help single-threaded code broke their programs. In my experience C compiler maintainers have generally been open to the idea of offering guarantees beyond a narrow reading of the standard, but the…

> the same place as suspicion of the "be lenient in what you accept" IETF principle

No. It's fine (arguably desireable, but reasonable people might disagree) for implementations that encounter undefined behaviour to terminate execution immediately, especially if it's with a error message. The problem is when implementations silently willfully misinterpret what they accept, particularly in ways that cause (not "expose"; reading from a null pointer and discarding the value (for example) isn't) security vulnerablities.

Post reply on HN