6 ms·

You might still make a mistake, even if you think you know the answer. It's much better to instrument the code to figure it out, or write a short test program.

by amelius 6mo ago

bestouff 6mo ago
It's Undefined Behavior. So you can instrument all you want, the answer will still be wrong. You'll capture what your particular compiler does under some particular conditions (opt flags, surrounding code, etc.) but that will not be representative of what can happen in the general case (hint : anything can happen with UB).
- amelius 6mo ago
  It doesn't matter if the answer is wrong. You run the test program and then replace the code by the answer. This basically weeds out the UB.
  - yongjik 6mo ago
    But since it is a UB, there's no guarantee that your test program produces the same result as the same code running on production, even if you have the same compiler.
    - amelius 6mo ago
      That's very unlikely, and in the worst case you've reduced a difficult bug into an easier to understand bug.
  - 1718627440 6mo ago
    That's a valid approach, if you only use high-level language to generate assembly faster, and the assembly is your source of truth.
- thaumasiotes 6mo ago
  > It's Undefined Behavior. Susam's post doesn't make this clear. The quotes from K&R say that the modifications to the variable may take place in any order, but they don't directly say that doing this is Undefined Behavior, which would make it permissible to do anything, including e.g. interpreting the increments as decrements. The C99 standard is quoted saying this: >> Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. It's possible that something else in the standard defines noncompliance with this clause as Undefined Behavior. But that's not the most intuitive interpretation; what this seems to say, to me, is that the line of code `a = a++ + ++a` should fail to compile, because it's not in compliance with a requirement of the language. Compilers that produce any result at all are suffering from a bug. (It seems more likely that the actual intent is to specify that, given the line of code `b = a++ + ++a`, with a initially equal to 5, the compiler is required to ensure that the value stored at the address of a is never equal to 6 - that it begins at 5, and at some indefinite point it becomes 7, but that there is no intermediate stage between them. But I find the 'compiler failure on attempt to put multiple modifications between two sequence points' interpretation preferable.)
  - Dylan16807 6mo ago
    Compilers are not able to prevent you from violating must/shall in the general case. So they're not held to that bar. Unless the standard says not to compile it, it's not a compiler bug. Also, imagine a situation where the line of code actually lists three different variables, but all three of them are passed in by address. It quickly becomes impossible for the compiler to know you violated the spec by reusing the same variable. And even optimizations that make sense here could corrupt the value pretty badly and possibly lead to worse errors.
    - thaumasiotes 6mo ago
      > Also, imagine a situation where the line of code actually lists three different variables, but all three of them are passed in by address. It quickly becomes impossible for the compiler to know you violated the spec by reusing the same variable. OK. What is the value of a spec to which compliance is impossible?
- tengwar2 6mo ago
  Not nasal demons in this case (https://groups.google.com/g/comp.std.c/c/ycpVKxTZkgw/m/S2hHdTbv4d8J https://groups.google.com/g/comp.std.c/c/ycpVKxTZkgw/m/S2hHd...): thaumasiotes shows that we can expect a numeric answer.
  - _kst_ 6mo ago
    I don't see the name "thaumasiotes" at that link, nor do I see anything relevant to the code in the title. The behavior of "int a = 5; a = a++ + ++a;" is undefined. There is no guarantee of a numeric result, because there is no guarantee of anything.
    - susam 6mo ago
      I believe they were referring to thaumasiotes's thread here: https://news.ycombinator.com/item?id=48141294 https://news.ycombinator.com/item?id=48141294 I think the objection thaumasiotes has raised there is valid and I have made an attempt to answer it as well in the same thread.
    - HarHarVeryFunny 6mo ago
      It's only the order of evaluation that is undefined.
      - afdbcreid 6mo ago
        Nope, there is no sequence point in the middle and modifying an object more than once between sequence points is undefined behavior.
      - _kst_ 6mo ago
        No, the behavior is undefined. That means, quoting the ISO C standard, "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements". A conforming implementation could reject it at compile time, or generate code that traps, or generate code that set a to 137, or, in principle, generate code that reformats your hard drive. Some of these behaviors are unlikely, but none are forbidden by the language standard.

You might still make a mistake, even if you think you know the answer. It's much better to instrument the code to figure it out, or write a short test program.

by amelius 6mo ago

You might still make a mistake, even if you think you know the answer. It's much better to instrument the code to figure it out, or write a short test program.

bestouff 6mo ago

It's Undefined Behavior. So you can instrument all you want, the answer will still be wrong. You'll capture what your particular compiler does under some particular conditions (opt flags, surrounding code, etc.) but that will not be representative of what can happen in the general case (hint : anything can happen with UB).

amelius 6mo ago
It doesn't matter if the answer is wrong. You run the test program and then replace the code by the answer. This basically weeds out the UB.
- yongjik 6mo ago
  But since it is a UB, there's no guarantee that your test program produces the same result as the same code running on production, even if you have the same compiler.
  - amelius 6mo ago
    That's very unlikely, and in the worst case you've reduced a difficult bug into an easier to understand bug.
- 1718627440 6mo ago
  That's a valid approach, if you only use high-level language to generate assembly faster, and the assembly is your source of truth.
thaumasiotes 6mo ago
> It's Undefined Behavior. Susam's post doesn't make this clear. The quotes from K&R say that the modifications to the variable may take place in any order, but they don't directly say that doing this is Undefined Behavior, which would make it permissible to do anything, including e.g. interpreting the increments as decrements. The C99 standard is quoted saying this: >> Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. It's possible that something else in the standard defines noncompliance with this clause as Undefined Behavior. But that's not the most intuitive interpretation; what this seems to say, to me, is that the line of code `a = a++ + ++a` should fail to compile, because it's not in compliance with a requirement of the language. Compilers that produce any result at all are suffering from a bug. (It seems more likely that the actual intent is to specify that, given the line of code `b = a++ + ++a`, with a initially equal to 5, the compiler is required to ensure that the value stored at the address of a is never equal to 6 - that it begins at 5, and at some indefinite point it becomes 7, but that there is no intermediate stage between them. But I find the 'compiler failure on attempt to put multiple modifications between two sequence points' interpretation preferable.)
- Dylan16807 6mo ago
  Compilers are not able to prevent you from violating must/shall in the general case. So they're not held to that bar. Unless the standard says not to compile it, it's not a compiler bug. Also, imagine a situation where the line of code actually lists three different variables, but all three of them are passed in by address. It quickly becomes impossible for the compiler to know you violated the spec by reusing the same variable. And even optimizations that make sense here could corrupt the value pretty badly and possibly lead to worse errors.
  - thaumasiotes 6mo ago
    > Also, imagine a situation where the line of code actually lists three different variables, but all three of them are passed in by address. It quickly becomes impossible for the compiler to know you violated the spec by reusing the same variable. OK. What is the value of a spec to which compliance is impossible?
tengwar2 6mo ago
Not nasal demons in this case (https://groups.google.com/g/comp.std.c/c/ycpVKxTZkgw/m/S2hHdTbv4d8J https://groups.google.com/g/comp.std.c/c/ycpVKxTZkgw/m/S2hHd...): thaumasiotes shows that we can expect a numeric answer.
- _kst_ 6mo ago
  I don't see the name "thaumasiotes" at that link, nor do I see anything relevant to the code in the title. The behavior of "int a = 5; a = a++ + ++a;" is undefined. There is no guarantee of a numeric result, because there is no guarantee of anything.
  - susam 6mo ago
    I believe they were referring to thaumasiotes's thread here: https://news.ycombinator.com/item?id=48141294 https://news.ycombinator.com/item?id=48141294 I think the objection thaumasiotes has raised there is valid and I have made an attempt to answer it as well in the same thread.
  - HarHarVeryFunny 6mo ago
    It's only the order of evaluation that is undefined.
    - afdbcreid 6mo ago
      Nope, there is no sequence point in the middle and modifying an object more than once between sequence points is undefined behavior.
    - _kst_ 6mo ago
      No, the behavior is undefined. That means, quoting the ISO C standard, "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements". A conforming implementation could reject it at compile time, or generate code that traps, or generate code that set a to 137, or, in principle, generate code that reformats your hard drive. Some of these behaviors are unlikely, but none are forbidden by the language standard.