I Do Not Know C: Short quiz on undefined behavior (2015)

Post by Kenji » Tue, Feb 14, 2017, 2:18 PM UTC

mauricioc wrote: post #138

Kenji wrote: post #131

I'm sorry, but the answer this website gives to 1. is wrong. See for yourself: int i; int i = 10; int main(int argc, char* argv[]){ return 0; } Try to compile it. It doesn't work (gcc.exe (GCC) 5.3.0), the error is: a.cc:2:5: error: redefinition of 'int i' int i = 10; ^ a.cc:1:5: note: 'int i' previously declared here int i; ^ Either I misunderstood the author and this example, or I do know C.

Judging by the .cc extension, you are compiling this with a C++ compiler. Quoting from Annex C (which documents the incompatibilities between C++ and ISO C) of the C++ standard: Change: C++ does not have “tentative definitions” as in C E.g., at file scope, int i; int i; is valid in C, invalid in C++. This makes it impossible to define mutually referential file-local static objects, if initializers are restricted to t…

Post by E6300 » Tue, Feb 14, 2017, 2:31 PM UTC

vyodaiken wrote: post #142

E6300 wrote: post #65

Earlier quoted context omitted.

> Therefore the compiler "proves" a false theorem. In the axiomatic system implied by the standard, the hypothetical compiler being discussed can prove that the null check can be eliminated. The fact that you believe this axiomatic system is inconvenient does not constitute a refutation of the truth of the theorem. > If the compiler is unable to prove a transformation preserves correctness, it should not do the trans…

the post that brought this to my attention discussed how a security error in Linux was created by this "optimization".

Post by rwj » Tue, Feb 14, 2017, 3:06 PM UTC

TorKlingberg wrote: post #120

DSMan195276 wrote: post #48

Earlier quoted context omitted.

I would agree that strict-aliasing is a hurt point for a lot of C devs, which is unfortunate. I'd only suggest that in general, if the strict-aliasing rule is coming into play you're probably already doing some really shady to begin with. Like in this example, casting a `long ` to an `int ` is likely a bad way to go about things even without worrying about strict-aliasing. In a lot of ways, I'd say that problems with…

A common class assignment or interview question is to write your own memcpy. Towards the end you usually start optimizing it by copying multiple bytes at once. That is undefined behavior. You cannot just cast a pointer to uint32_t* and start using it, unless the underlying object is actually uint32_t. In practice it works fine, so people don't care. We'll see what future compilers will do, especially when the homemad…

Post by yorwba » Tue, Feb 14, 2017, 3:27 PM UTC

to3m wrote: post #127

scatters wrote: post #126

Earlier quoted context omitted.

If you want the compiler to leave the dereferences in, use `-fno-delete-null-pointer-checks` or ask your compiler vendor for an equivalent option. Compilers delete null pointer checks by default (on typical platforms) because it's what most users want.

But the null pointer check was left in. (And, sure enough, adding -fno-delete-null-pointer-checks makes no difference.)

    foo(int*):                               # @foo(int*)
        test    rdi, rdi
        je      .LBB0_1
        mov     edi, dword ptr [rdi]
        jmp     bar(int)                 # TAILCALL
    .LBB0_1:
        ret

Post by mfukar » Tue, Feb 14, 2017, 3:38 PM UTC

vyodaiken wrote: post #139

lmm wrote: post #129

Earlier quoted context omitted.

This battle has been fought and lost. If you require sensible behaviour, just move on and use a language that offers it. C compilers will do what makes them look good on benchmarks, and various "friendly C" efforts have been tried and failed.

Au contraire - gcc and clang both appear to do the right thing now.