3 ms·

Exactly. You are assuming that a poorly written standard is correct and engineering practice of working programs is incorrect.

msbarnett 10y ago
Ok, so you want compilers to generate a translation for program #2 that works "correctly" to your mind when x is null. Please explain to the class the meaning of the construct int y = *x; when x is null, so that all conforming C compilers can be updated to generate code for this case "correctly".
- yorwba 10y ago
  Something like assert(x); int y = *x; is probably closer to the intended meaning. Checking if(!x) afterwards is still dead code, but at least the program is guaranteed to fail in a defined manner. Of course, if implemented this way, every dereference would have to be paired with an assert call, bringing the performance down to the level of Java. (While bringing the memory safety up to the level of Java.)
  - msbarnett 10y ago
    That's the opposite of what he wants. He wants a compiler that produces a translation which derefrences the null and follows the true branch. He wants null to equal a valid addressable address, which is completely nonstandard and not portable to everywhere C is used, to be standard that portable compilers emit code for. He wants to imagine that null and zero are the same thing.
    - vyodaiken 10y ago
      Nobody wants that.
  - to3m 10y ago
    If the code for program #2 isn't enough to describe the desired behaviour, perhaps it isn't expressible in terms of standard C. Here's what "x86-64 clang 3.9.1" gives for foo with -O3: (https://godbolt.org/g/0xe1OD https://godbolt.org/g/0xe1OD) foo(int*): # @foo(int*) test rdi, rdi je .LBB0_1 jmp bar() # TAILCALL .LBB0_1: ret (You might like to compare this with the article's claims.) More the sort of thing that I'd expect to be generated (since it's a more accurate rendering of the C code): foo(int*): # @foo(int*) mov eax, [rdi] test rdi, rdi je .LBB0_1 jmp bar() # TAILCALL .LBB0_1: ret I know that NULL is a valid address on x64 (it's zero), and on any system that doesn't completely suck it will be unmapped. (If I'm using one of the ones that sucks, I'll already be prepared for this. But luckily I'm not.) So I'd like to feel confident that the compiler will just leave the dereferences in - that way, when I make some horrid mistake, I'll at least get an error at runtime. But rather than compile my mistakes as written, it seems that the compiler would prefer to double down on them.
    - scatters 10y ago
      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.
      - to3m 10y ago
        But the null pointer check was left in. (And, sure enough, adding -fno-delete-null-pointer-checks makes no difference.)
        yorwba 10y ago
        That's because y is never used, so why should the pointer be dereferenced? If you call bar(y) instead of just bar(), "x86-64 clang 3.9.1" with -O3 does the load as well (but after the check) foo(int*): # @foo(int*) test rdi, rdi je .LBB0_1 mov edi, dword ptr [rdi] jmp bar(int) # TAILCALL .LBB0_1: ret Only GCC does the kind of aggressive optimization the article mentions (and might need to be tamed by -fno-delete-null-pointer-checks).
deleted 10y ago
[deleted]

msbarnett 10y ago

Ok, so you want compilers to generate a translation for program #2 that works "correctly" to your mind when x is null. Please explain to the class the meaning of the construct int y = *x; when x is null, so that all conforming C compilers can be updated to generate code for this case "correctly".

yorwba 10y ago
Something like assert(x); int y = *x; is probably closer to the intended meaning. Checking if(!x) afterwards is still dead code, but at least the program is guaranteed to fail in a defined manner. Of course, if implemented this way, every dereference would have to be paired with an assert call, bringing the performance down to the level of Java. (While bringing the memory safety up to the level of Java.)
- msbarnett 10y ago
  That's the opposite of what he wants. He wants a compiler that produces a translation which derefrences the null and follows the true branch. He wants null to equal a valid addressable address, which is completely nonstandard and not portable to everywhere C is used, to be standard that portable compilers emit code for. He wants to imagine that null and zero are the same thing.
  - vyodaiken 10y ago
    Nobody wants that.
- to3m 10y ago
  If the code for program #2 isn't enough to describe the desired behaviour, perhaps it isn't expressible in terms of standard C. Here's what "x86-64 clang 3.9.1" gives for foo with -O3: (https://godbolt.org/g/0xe1OD https://godbolt.org/g/0xe1OD) foo(int*): # @foo(int*) test rdi, rdi je .LBB0_1 jmp bar() # TAILCALL .LBB0_1: ret (You might like to compare this with the article's claims.) More the sort of thing that I'd expect to be generated (since it's a more accurate rendering of the C code): foo(int*): # @foo(int*) mov eax, [rdi] test rdi, rdi je .LBB0_1 jmp bar() # TAILCALL .LBB0_1: ret I know that NULL is a valid address on x64 (it's zero), and on any system that doesn't completely suck it will be unmapped. (If I'm using one of the ones that sucks, I'll already be prepared for this. But luckily I'm not.) So I'd like to feel confident that the compiler will just leave the dereferences in - that way, when I make some horrid mistake, I'll at least get an error at runtime. But rather than compile my mistakes as written, it seems that the compiler would prefer to double down on them.
  - scatters 10y ago
    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.
    - to3m 10y ago
      But the null pointer check was left in. (And, sure enough, adding -fno-delete-null-pointer-checks makes no difference.)
      - yorwba 10y ago
        That's because y is never used, so why should the pointer be dereferenced? If you call bar(y) instead of just bar(), "x86-64 clang 3.9.1" with -O3 does the load as well (but after the check) foo(int*): # @foo(int*) test rdi, rdi je .LBB0_1 mov edi, dword ptr [rdi] jmp bar(int) # TAILCALL .LBB0_1: ret Only GCC does the kind of aggressive optimization the article mentions (and might need to be tamed by -fno-delete-null-pointer-checks).

deleted 10y ago

[deleted]