6 ms·

What behavior should the following have: int f(int x) { switch (x) { case 0: return 31; case 1: return 28; case 2: return 3

What behavior should the following have: int f(int x) { switch (x) { case 0: return 31; case 1: return 28; case 2: return 30; } } This code on its own has no undefined behavior. In another translation unit, someone calls `f(3)`. What would you have compilers do in that case? That path through the program has undefined behavior. However, the two translation units are separate and as such normal tooling will not be able to detect any sort of UB without some kind of whole program static analysis or heavy instrumentation which would harm performance.

torstenvl 2y ago
I would do what the standard tells me to do, which is to ignore the undefined behavior if I don't detect it. On most platforms, that would probably result in the return value of 3 (it would still be in AX, EAX, r0, x0, o0/i0, whatever, when execution hits the ret instruction or whatever that ISA/ABI uses to mark the end of the function). But it would be undefined. But that's fine. [EDIT: I misremembered the x86 calling convention, so my references to AX and EAX are wrong above. Mea culpa.] What isn't fine is ignoring the end of the function, not emitting a ret instruction, and letting execution fall through to the next label/function, which is what I suspect GCC does.
- cokernel_hacker 2y ago
  So let's change it up a bit. typedef int (*pfn)(void); int g(void); int h(void); pfn f(double x) { switch ((long long)x) { case 0: return g; case 17: return h; } } If I understand your perspective correctly, `f` should return whatever happens to be in rax if the caller does not pass in a number which truncates to 0 or 17?
  - torstenvl 2y ago
    More or less, yes. I quibble with "should return" because I don't think it's accurate to say it "should" do anything in any specific set of circumstances. In fact, I'm saying the opposite: it should generate the generic, semantic code translation of what is actually written in source, and if it happens to "return whatever happens to be in rax" (as is likely on x64), then so be it. In my view, that's what "ignoring the situation completely with unpredictable results" means.
- nlewycky 2y ago
  Why isn't that fine? The compiler ignored the undefined behavior it didn't detect.
  - torstenvl 2y ago
    No. No honest person can claim that making a decision predicated on the existence of X is the same as "ignoring" X.
    - nlewycky 2y ago
      This is the most normal case though, isn't it? Suppose a very simple compiler, one that sees a function so it writes out the prologue, it sees the switch so it writes out the jump tables, it sees each return statement so it writes out the code that returns the values, then it sees the function closing brace and writes out a function epilogue. The problem is that the epilogue is wrong because there is no return statement returning a value, the epilogue is only correct if the function has void return type. Depending on ABI, the function returns to a random address. Most of the time people accuse compilers of finding and exploiting UB and say they wish it would just emit the straight-forward code, as close to writing out assembly matching the input C code expression by expression as possible. Here you have an example where the compiler never checked for UB let alone proved presence of UB in any sense, it trusted the user, it acted like a high-level assembler, yet this compiler is still not ignoring UB for you? What does it take? Adding runtime checks for the UB case is ignoring? Having the compiler find the UB paths to insert safety code is ignoring?
      - torstenvl 2y ago
        > the epilogue is only correct if the function has void return type That's a lie. > Adding runtime checks for the UB case is ignoring? Having the compiler find the UB paths to insert safety code is ignoring? Don't come onto HN with the intent of engaging in bad faith.
        nlewycky 2y ago
qiqitori 2y ago
This won't compile with reasonable compiler flags. (-Wall and a reasonable set of -Werror settings). Now, assume that you didn't compile this with those flags; what actually happens is entirely obvious but platform-dependent. Assume amd64 (and many other architectures) where the return value is in the "accumulator register", assume that int is 32 bits. The return value will be whatever was in eax. The called function doesn't set eax (or maybe does in order to implement some unrelated surrounding code). The caller takes eax without knowledge of where it came from.
zzo38computer 2y ago
What I would have it to do is: Return a number that is in the range of the "int" type, but there is no guarantee what number it will be, and it will not necessarily be consistent when called more than once, when the program is executed more than once (unless the operating system has features to enforce consistent behaviour), when the program is compiled for and running on a different computer, etc. I would also have the undefined value to be frozen, like the "freeze" command in LLVM. Normally, the effect would be according to the target instruction set, because it would be compiled in the best way for that target instruction set. Depending on the compiler options, it might also display a warning that not all cases are handled, although this warning would be disabled by default. (However, some instruction sets might allow it to be handled differently; e.g. if you have an instruction set with tagged pointers that can be stored in ordinary registers and memory, then there is the possibility that trying to use the return value causes an error condition.)
loeg 2y ago
In a new language that isn't C, that function shouldn't compile at all (missing return). In a C compiler, inserting a trap (x86 ud2, for example) might be reasonable.

torstenvl 2y ago

I would do what the standard tells me to do, which is to ignore the undefined behavior if I don't detect it. On most platforms, that would probably result in the return value of 3 (it would still be in AX, EAX, r0, x0, o0/i0, whatever, when execution hits the ret instruction or whatever that ISA/ABI uses to mark the end of the function). But it would be undefined. But that's fine. [EDIT: I misremembered the x86 calling convention, so my references to AX and EAX are wrong above. Mea culpa.] What isn't fine is ignoring the end of the function, not emitting a ret instruction, and letting execution fall through to the next label/function, which is what I suspect GCC does.

cokernel_hacker 2y ago
So let's change it up a bit. typedef int (*pfn)(void); int g(void); int h(void); pfn f(double x) { switch ((long long)x) { case 0: return g; case 17: return h; } } If I understand your perspective correctly, `f` should return whatever happens to be in rax if the caller does not pass in a number which truncates to 0 or 17?
- torstenvl 2y ago
  More or less, yes. I quibble with "should return" because I don't think it's accurate to say it "should" do anything in any specific set of circumstances. In fact, I'm saying the opposite: it should generate the generic, semantic code translation of what is actually written in source, and if it happens to "return whatever happens to be in rax" (as is likely on x64), then so be it. In my view, that's what "ignoring the situation completely with unpredictable results" means.
nlewycky 2y ago
Why isn't that fine? The compiler ignored the undefined behavior it didn't detect.
- torstenvl 2y ago
  No. No honest person can claim that making a decision predicated on the existence of X is the same as "ignoring" X.
  - nlewycky 2y ago
    This is the most normal case though, isn't it? Suppose a very simple compiler, one that sees a function so it writes out the prologue, it sees the switch so it writes out the jump tables, it sees each return statement so it writes out the code that returns the values, then it sees the function closing brace and writes out a function epilogue. The problem is that the epilogue is wrong because there is no return statement returning a value, the epilogue is only correct if the function has void return type. Depending on ABI, the function returns to a random address. Most of the time people accuse compilers of finding and exploiting UB and say they wish it would just emit the straight-forward code, as close to writing out assembly matching the input C code expression by expression as possible. Here you have an example where the compiler never checked for UB let alone proved presence of UB in any sense, it trusted the user, it acted like a high-level assembler, yet this compiler is still not ignoring UB for you? What does it take? Adding runtime checks for the UB case is ignoring? Having the compiler find the UB paths to insert safety code is ignoring?
    - torstenvl 2y ago
      > the epilogue is only correct if the function has void return type That's a lie. > Adding runtime checks for the UB case is ignoring? Having the compiler find the UB paths to insert safety code is ignoring? Don't come onto HN with the intent of engaging in bad faith.
      - nlewycky 2y ago

qiqitori 2y ago

This won't compile with reasonable compiler flags. (-Wall and a reasonable set of -Werror settings). Now, assume that you didn't compile this with those flags; what actually happens is entirely obvious but platform-dependent. Assume amd64 (and many other architectures) where the return value is in the "accumulator register", assume that int is 32 bits. The return value will be whatever was in eax. The called function doesn't set eax (or maybe does in order to implement some unrelated surrounding code). The caller takes eax without knowledge of where it came from.

zzo38computer 2y ago

What I would have it to do is: Return a number that is in the range of the "int" type, but there is no guarantee what number it will be, and it will not necessarily be consistent when called more than once, when the program is executed more than once (unless the operating system has features to enforce consistent behaviour), when the program is compiled for and running on a different computer, etc. I would also have the undefined value to be frozen, like the "freeze" command in LLVM. Normally, the effect would be according to the target instruction set, because it would be compiled in the best way for that target instruction set. Depending on the compiler options, it might also display a warning that not all cases are handled, although this warning would be disabled by default. (However, some instruction sets might allow it to be handled differently; e.g. if you have an instruction set with tagged pointers that can be stored in ordinary registers and memory, then there is the possibility that trying to use the return value causes an error condition.)

loeg 2y ago

In a new language that isn't C, that function shouldn't compile at all (missing return). In a C compiler, inserting a trap (x86 ud2, for example) might be reasonable.