Fun with UB in C: returning uninitialized floats

http://yosefk.com/blog/fun-with-ub-in-c-returning-uninitialized-floats.html

by luu • 11 years ago

44 35 11 years ago

Filligree• 11 years ago

Can I just suggest that... forcing programmers to become language lawyers just so their language-lawyer compilers don't get overly clever and optimise away half their program is probably a bad thing?

aciuix6• 11 years ago

For that to happen the programmer had to be overly clever in the first place, in which case it is his own fault.

If you stick to what is taught in any good tutorial/book, you don't even have to think about problems like this.

But if you decide to play with fire, then you should read the Standard and understand it.

rcfox6• 11 years ago

It's not hard to get into undefined behaviour territory with seemingly correct code. For example: signed integer overflow is undefined in C.

cremno• 11 years ago

Or just read the diagnostics and fix the code (or use UBSan). Clang outputs:

variable 'c' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]

userbinator2• 11 years ago

In fact, I'd say that such optimisations which assume no UB and remove code as a result are probably working against the programmer's intention. From its origins as a "portable assembler", C was never supposed to be a very high-level language anyway; I think the compiler should optimise only with respect to things like instruction selection, and UB should be treated as "behaving during translation or program execution in a documented manner characteristic of the environment" (this is an actual quote from the standard.)

rcfox6• 11 years ago

Sure, but then we'd just be discussing undefined behaviour in the language that sprung up out of the desire to take advantage of the optimizations that the neutered C leaves on the table.

Peaker• 11 years ago

If I write a bunch of code in a macro, or a function that happens to get inlined -- much of its code may be irrelevant in the specific context into which it was inlined.

I don't want to duplicate the code for every single context it is used in -- so I'm happy the compiler can throw away pieces of the code that aren't relevant in each inlined context.

OTOH, for ordinary non-inlined code, I really want a warning if my code is thrown away or optimized in a surprising manner.

Indeed, gcc and clang try to behave according to the two ideas above. gcc violates this terribly with its removal of dead code warnings -- which may be eliminated but no warnings are generated.

rcfox6• 11 years ago

Someone says this every time the topic of undefined behaviour comes up.

Ignoring the original portability concerns, there's a large of set of optimizations that are only possible if you can assume that no undefined behaviour occurs.

Accessing past the bounds of an array is undefined, and generally a bad thing to do. If the compiler decides that a block of code could only run if you access outside of the array, why not delete that code? Surely, it'll never run!

Even eliminating array bounds checking is an optimization that requires the assumption that you don't go past the end of the array. Languages like Java and Python pay a premium to ensure you don't do this on each iteration of your for loops.

titzer• 11 years ago

There is essentially no C compiler that bounds checks arrays, so your comment is a total red herring. This is not an instance where exploiting UB leads to faster code.

And, for Java, JITs do a lot of work to remove bounds checks from loops over arrays so that you end up with the fastest possible machine code.

_yosefk2• 11 years ago

The thing is, reading past the bounds of an array can be harmless at the machine level and useful for optimization.

So it being UB means you've got a compiler which can optimize better but the cost is that you tied the programmer's hands, so the programmer's optimization opportunities are in fact reduced. And you didn't even tie them, the annoying thing is, rather you laid traps that they can fall into because of failing to notice them.

(I'm not saying C made the wrong tradeoff with declaring this or that UB, just that the tradeoff exists.)

thoughtpolice• 11 years ago

Surely, it'll never run!

Oh, the hilarious irony of giving language-lawyery, glib responses of "obviously, the code will not run" to users (who probably, you know, wrote code with the intention of it running) - users who are complaining about language lawyering optimizing compilers in the first place. It's like two people reading the same page in a different book or something.

EliRivers• 11 years ago

If you aren't happy with the trade-offs of using such languages, don't use them.

ge0rg• 11 years ago

This is especially true when the compiler removes security-relevant range checks from the code because the developer used the wrong type / parameter order and thus caused UB.

panic• 11 years ago

Is this really undefined behavior? The C spec says (6.7.8.10) "If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate." The fact that the indeterminate value could be a signaling NaN is a feature of floating point numbers, not C.

aciuix6• 11 years ago

The example shown in the article is in fact undefined behavior:

6.3.2.1,p2 If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.

_yosefk2• 11 years ago

The funny thing is, returning it just to discard it constitutes "use", apparently.

userbinator2• 11 years ago

That seems like a very unusual way to define a function. I'd want 'ok' to be the return value, and the actual value returned to be via the pointer, since that allows for

    float c;
    if(get(v, &c))
     ...do something with c...

instead of the more verbose

    bool ok;
    float c;
    c = get(v, &ok);
    if(ok)
     ...do something with c...

aciuix6• 11 years ago

I think it is a matter of being consistent. Both ways have certain syntactic dis/advantages.

The first one enables you to have the function call directly in the if statement, but requires you to define a variable beforehand.

The latter gives you the option to check the return value, pass a NULL, if you don't need it for example, and use the return value directly.

exDM69• 11 years ago

This is an interesting corner case but I'd like to see a practical piece of code that actually causes this issue when compiled and executed. The example code is quite contrived and compiler warnings should be raised.

Further, does the signalling NaN behavior happen with SSE (or NEON) or is this an x87 issue?

stephencanon• 11 years ago

The default behavior in every OS with which I'm familiar (this is specified by IEEE-754) is for x87, SSE, VFP and NEON not to trap on signaling NaNs. You have to explicitly unmask the invalid floating-point exception in order for this to trap. All that would happen with the default floating-point environment is that the invalid flag would be raised in FPCR.

IIRC, FSTP st(0), to simply clear the stack without using the result as discussed in the article, doesn't even generate #IA, so it can't trap or raise invalid (it only generates #IA when the store converts to a smaller FP type (fun fact: this is so FLD/FSTP could be used to implement memcpy way back when))

Fun with UB in C: returning uninitialized floats

Related Stories