5 ms·

Very interesting, to me seems like a "compiler bug". The compiler should not automatically set the static pointer value if the function that sets it is never ca

by XCSme 9y ago

Very interesting, to me seems like a "compiler bug". The compiler should not automatically set the static pointer value if the function that sets it is never called. Anyway, I guess "undefined behavior" is really undefined and it means anything can happen, so as per specs it's not a bug. Ultimately it's the programmer's mistake for having undefined behavior in his code.

electrograv 9y ago
Unfortunately, "it's not a bug, it's a feature!" -- there are long-standing design choices in C/C++ where various circumstances are explicitly designed to yield "undefined" behavior where literally anything goes. I believe the original intent of these are to give the compiler/optimizer more room to speed up the executable. Edit: The 'undefined' clause here is due to invoking a function at address 0, rather than any lack of variable initialization (since global variables are automatically initialized to 0, as the poster below points out).
- mikeash 9y ago
  Globals are always initialized. If no initial value is specified, they’re initialized to zero. What’s undefined here is calling a function pointer that contains zero. Thus the compiler assumes that it must have been set before being called, and since there’s only one value it could possibly be set to, it must be that value.
- lisper 9y ago
  It is a bug, but it's a bug in the spec. Saying that a common mistake like dereferencing the null pointer is undefined and therefore your program can do anything is not useful behavior. The only sane design is for any attempt to dereference the null pointer to cause the program to signal an error somehow. Exactly how that happens can be left unspecified, but that it must happen cannot be unspecified in a sane design. I don't see how any reasonable person could possibly dispute this.
  - jcranmer 9y ago
    > Exactly how that happens can be left unspecified, but that it must happen cannot be unspecified in a sane design. I don't see how any reasonable person could possibly dispute this. Your proposal is basically tantamount to saying that the compiler can never ever delete any read or write to memory that is unused if it can't prove that the memory pointer is non-null (for example, the pointer is an argument to the function--clearly a very common case). Trying to formally specify what can and can't be done with common undefined cases (like dereferencing memory that results in a trap or reading uninitialized values) turns out to run into issues where the specification unintentionally precludes common optimizations, and it's not always clear how to word semantics in such a way to not do that.
    - lisper 9y ago
      > Your proposal is basically tantamount to saying that the compiler can never ever delete any read or write to memory that is unused if it can't prove that the memory pointer is non-null That's right. I would much prefer to take a small performance hit if I might be dereferencing a null pointer than to literally have anything at all happen in that case. If I really need that last little bit of performance I really do want my compiler to insist that my code be correct before it will give it to me rather than take a wild guess at what I really meant to do and get it wrong.
      - richardwhiuk 9y ago
        How big a performance hit? Double run time? Triple? 10x?
        lisper 9y ago
        I will take any performance hit over the potential for catastrophic failure by default.
        umanwizard 9y ago
        Then there is an easy solution: compile with -O0. What's the problem with optimizations being available for those who want them?
eridius 9y ago
How do you know it's never called? You can call the function from another file. It's not possible to know that the function is never called until link time.
- gmueckl 9y ago
  No, the function pointer is declared static. It cannot be referred to outside the current file.
  - DSrcl 9y ago
    The function pointer is static. But the function that mutates it, NeverCalled, is not. One can still indirectly change that function pointer.
deleted 9y ago
[deleted]
cesarb 9y ago
> The compiler should not automatically set the static pointer value if the function that sets it is never called. It doesn't automatically set the pointer value. It only assumes, when reading the pointer, that it can only be NULL or EraseAll (NULL is the initial value, EraseAll is the value set by NeverCalled, since the pointer is visible only to the same C file there are no other possibilities). Then it sees a function call through the pointer, and assumes it cannot be NULL (you can't dereference a NULL pointer, much less call through it). The only value left is EraseAll; since that's the only possibility, it is inlined at the call site. At no moment was the static pointer value modified.

by XCSme 9y ago

electrograv 9y ago

Unfortunately, "it's not a bug, it's a feature!" -- there are long-standing design choices in C/C++ where various circumstances are explicitly designed to yield "undefined" behavior where literally anything goes. I believe the original intent of these are to give the compiler/optimizer more room to speed up the executable. Edit: The 'undefined' clause here is due to invoking a function at address 0, rather than any lack of variable initialization (since global variables are automatically initialized to 0, as the poster below points out).

mikeash 9y ago
Globals are always initialized. If no initial value is specified, they’re initialized to zero. What’s undefined here is calling a function pointer that contains zero. Thus the compiler assumes that it must have been set before being called, and since there’s only one value it could possibly be set to, it must be that value.
lisper 9y ago
It is a bug, but it's a bug in the spec. Saying that a common mistake like dereferencing the null pointer is undefined and therefore your program can do anything is not useful behavior. The only sane design is for any attempt to dereference the null pointer to cause the program to signal an error somehow. Exactly how that happens can be left unspecified, but that it must happen cannot be unspecified in a sane design. I don't see how any reasonable person could possibly dispute this.
- jcranmer 9y ago
  > Exactly how that happens can be left unspecified, but that it must happen cannot be unspecified in a sane design. I don't see how any reasonable person could possibly dispute this. Your proposal is basically tantamount to saying that the compiler can never ever delete any read or write to memory that is unused if it can't prove that the memory pointer is non-null (for example, the pointer is an argument to the function--clearly a very common case). Trying to formally specify what can and can't be done with common undefined cases (like dereferencing memory that results in a trap or reading uninitialized values) turns out to run into issues where the specification unintentionally precludes common optimizations, and it's not always clear how to word semantics in such a way to not do that.
  - lisper 9y ago
    > Your proposal is basically tantamount to saying that the compiler can never ever delete any read or write to memory that is unused if it can't prove that the memory pointer is non-null That's right. I would much prefer to take a small performance hit if I might be dereferencing a null pointer than to literally have anything at all happen in that case. If I really need that last little bit of performance I really do want my compiler to insist that my code be correct before it will give it to me rather than take a wild guess at what I really meant to do and get it wrong.
    - richardwhiuk 9y ago
      How big a performance hit? Double run time? Triple? 10x?
      - lisper 9y ago
        I will take any performance hit over the potential for catastrophic failure by default.
        umanwizard 9y ago
        Then there is an easy solution: compile with -O0. What's the problem with optimizations being available for those who want them?

eridius 9y ago

How do you know it's never called? You can call the function from another file. It's not possible to know that the function is never called until link time.

gmueckl 9y ago
No, the function pointer is declared static. It cannot be referred to outside the current file.
- DSrcl 9y ago
  The function pointer is static. But the function that mutates it, NeverCalled, is not. One can still indirectly change that function pointer.

deleted 9y ago

[deleted]

cesarb 9y ago

> The compiler should not automatically set the static pointer value if the function that sets it is never called. It doesn't automatically set the pointer value. It only assumes, when reading the pointer, that it can only be NULL or EraseAll (NULL is the initial value, EraseAll is the value set by NeverCalled, since the pointer is visible only to the same C file there are no other possibilities). Then it sees a function call through the pointer, and assumes it cannot be NULL (you can't dereference a NULL pointer, much less call through it). The only value left is EraseAll; since that's the only possibility, it is inlined at the call site. At no moment was the static pointer value modified.