Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Int a = 5; a = a++ + ++a; a =? (2011)

gynvael.coldwind.pl

Post reply on HN
Print view View original

101–110 of 246 posts

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#101

Post by amelius »

bestouff wrote: post #97
amelius wrote: post #83

Earlier quoted context omitted.

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.

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).

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.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#102

Post by suprjami »

compiler-guy wrote: post #19

With undefined behavior, a conforming compiler can do anything it wants at all, including generating a program that segfaults or something else. But what often happens in practice is that "Bill's Fly-By-Night-C-Compiler-originally-written-in-the-mid-nineties" implemented it in some specific way (probably by accident) and maintains it as a (probably informal) extension. And almost certainly has users who depend on it,…

> including generating a program that segfaults or something else.

UB = run nethack or Emacs:

https://feross.org/gcc-ownage/

We should have kept this behaviour. It would make UB a lot more unpalatable and easy to find.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#103

Post by Karliss »

compiler-guy wrote: post #37
bombcar wrote: post #25

Earlier quoted context omitted.

I feel we need another category - unspecified behavior. I think everyone would agree the compiler should putout ONE of those answers and that nasal demons would be out of spec. The problem is that it’s not specified which should be picked, but all pick something.

The C and C++ standards include "Implementation defined behavior", which means that a conforming implementation can do whatever it wants, as long as it specifically documents and sticks to that behavior. This doesn't really help portability all that much.

That's a different category. Standard defines and uses all 3 "undefined", "implementation defined" and "unspecified" behavior. The difference between last two is that compiler isn't required to document exact behavior. Unlike UB triggering it doesn't automatically summon nasal demons and range of possible behaviors is usually described by standard.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#105

Post by thaumasiotes »

bestouff wrote: post #97
amelius wrote: post #83

Earlier quoted context omitted.

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.

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).

> 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.)

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#106

Post by dmoy »

chasd00 wrote: post #100
susam wrote: post #5

The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the co…

Genuinely curious, so this is undefined behavior and depends on the compiler. I get that. Java, and other languages, can do these same operations but their compilers produce bytecode that runs on a virtual machine (JVM) compiled to machine code just-in-time. Would this same code in Java possibly yield different results based on the platform the JVM was running on because of the platform specific JIT compiler? Maybe t…

> Would this same code in Java possibly yield different results based on the platform the JVM was running on because of the platform specific JIT compiler?

No, and it's also well defined in languages like C#.

If we're talking about this specific example at least. No sequence point issues like that in Java.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#107

Post by Crespyl »

chasd00 wrote: post #100
susam wrote: post #5

The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the co…

Genuinely curious, so this is undefined behavior and depends on the compiler. I get that. Java, and other languages, can do these same operations but their compilers produce bytecode that runs on a virtual machine (JVM) compiled to machine code just-in-time. Would this same code in Java possibly yield different results based on the platform the JVM was running on because of the platform specific JIT compiler? Maybe t…

It's been quite a while, but IIRC, in Java these statements actually do have a defined behavior.

The ++x is a "pre-increment", meaning the value of the variable is incremented prior to evaluating the expression, while the "post-increment" "x++" is the other way around: the expression evaluates to x, then x is incremented afterwards.

All expressions are left-to-right.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#108

Post by Dylan16807 »

thaumasiotes wrote: post #105
bestouff wrote: post #97

Earlier quoted context omitted.

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).

> 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…

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.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#109

Post by monocasa »

cesaref wrote: post #44
saghm wrote: post #20

Earlier quoted context omitted.

Honestly, having increment in expressions rather than a statement feels like more of a footgun than a benefit. Expressions shouldn't mutate things.

I think the history of this is that these operations were common with assembly programmers, so when C came along, these were included in the language to allow these developers to feel they weren't leaving lots of performance behind. Look at the addressing modes for the PDP-11 in https://en.wikipedia.org/wiki/PDP-11_architecture and you'll see you can write (R0)+ to read the contents of the location pointed to by R0,…

Additionally, those indirect memory instructions ended up disappearing because it complicated virtual memory implementations. It was a pain in the ass to describe the multiple places in memory an instruction could be accessing and which actually faulted to a fault handler, not to mention having to roll back all that state on more complex designs.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#110

Post by kencausey »

chasil wrote: post #69
Timwi wrote: post #65

The statement is valid C#, which has left-to-right execution order and no undefined behavior. The answer is 5 + 7 = 12.

Awk also says it's 12. awk 'BEGIN{a=5; a = a++ + ++a; print a}' 12

https://www.gnu.org/software/gawk/manual/gawk.html#index-pre...

"When side effects happen is implementation-defined. In other words, it is up to the particular version of awk."

Post reply on HN