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

121–130 of 246 posts

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

#121

Post by Boxxed »

bombcar wrote: post #25
Boxxed wrote: post #14

> The interesting thing here is the Undefined Behavior (UB), well... actually two UBs, thanks to which there are three possible correct answers: 11, 12 and 13. No, if you invoke undefined behavior any result at all is possible.

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.

That already exists, and it is in fact called unspecified behavior. Order of function argument evaluation is unspecified, for instance.

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

#122

Post by tengwar2 »

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

Not nasal demons in this case (https://groups.google.com/g/comp.std.c/c/ycpVKxTZkgw/m/S2hHd...): thaumasiotes shows that we can expect a numeric answer.

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

#123

Post by [deleted] »

tredre3 wrote: post #118
Crespyl wrote: post #107

Earlier quoted context omitted.

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.

That behavior is inherited from C. The pre/post increment behavior is actually the same in every language that uses them. The priority of operation is also usually the same as well. The reason the question is tricky is because those operators change the value of a as the full expression is progressively executed. It's not immediately clear to me what the answer in Java would be. Just take a++ + ++a for example: If th…

[deleted]

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

#124

Post by rmu09 »

vcdk wrote: post #117
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…

Well... tried it on macOS using vanilla gcc, the results surprised me: $ /bin/cat x.c; gcc -w -o x x.c; ./x #include int main() { int a = 5; a += a++ + a++; printf("a = %d\n", a); } a = 18 Not what I expected. This must be how it works: - The first a++ expression results in 5, after a = 6 - The second a++ expression results in 6, after a = 7 - Only then the LHS a is evaluated for the addition-assignment, so we get: a…

the original question has a=, you have a+=

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

#125

Post by Karliss »

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…

The UB comes from how C++ standard defines expression sequencing which is not relevant for Java. Languages other than C++ typically define such details more strictly so there is no UB or even concept of UB. JIT compilers don't change it as any non toy JIT will generate native instructions directly or through intermediate representation (instead of generating C++ text and passing that through regular C++ compiler) both of which should have much stricter semantics compared to what C++ guarantees.

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

#126

Post by kibwen »

fc417fc802 wrote: post #76
kibwen wrote: post #58

Earlier quoted context omitted.

> I don't see what it has to do with for loops or operators specifically. The reason that these operators pull their weight in C is because iteration over arrays is achieved by manual incrementation (usually via the leading clauses of the for-loop) followed by direct indexing. Languages with a first-class notion of iteration don't directly index in this way, which overwhelmingly eliminates not only the vast majority…

For loops are hardly the only usecase and built in iteration constructs frequently fall short. For example any mildly complex loop that involves pointer juggling can benefit. > which doesn't have the footguns of `++` due to assignment being a statement rather than expression, So then I implement the local equivalent of inc( v ) and ... same issue, right? Plus with rust macros is there any technical reason you can't t…

> For example any mildly complex loop that involves pointer juggling can benefit.

I'd say that when you're writing a mildly complex loop that involves pointer juggling, one should prefer to be defensive and explicit rather than cleverly trying to compress everything into one-liners.

> So then I implement the local equivalent of inc( v ) and ... same issue, right?

This isn't done in Rust because there's no benefit. It's rare to find an occasion where it's necessary to do something tricky enough to forego using iterators, and when working with raw pointers Rust code just plain doesn't use basic addition for pointer arithmetic; instead it has a variety of pointer arithmetic methods for being explicit about the desired semantics (e.g. ptr::add, ptr::offset, ptr::wrapping_add, etc).

> Plus with rust macros is there any technical reason you can't trivially implement ++ for yourself?

There's not, but people might look at you sideways. Here, I implemented it for you: https://play.rust-lang.org/?version=stable&mode=debug&editio... . It expands to nested blocks with internal assignments, which results in a well-defined semantics following the defined order of evaluation in Rust.

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

#127

Post by amelius »

yongjik wrote: post #112
amelius wrote: post #101

Earlier quoted context omitted.

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.

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.

That's very unlikely, and in the worst case you've reduced a difficult bug into an easier to understand bug.

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

#128

Post by Dylan16807 »

thaumasiotes wrote: post #113
Dylan16807 wrote: post #108

Earlier quoted context omitted.

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

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

Welcome to C.

But more seriously it's the job of the program to not do undefined things.

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

#129

Post by tombert »

amavect wrote: post #82
tombert wrote: post #52

I have always hated this crap; the fact that I'm not 100% sure the result of this indicates that maybe the ++ operator (pre or postfix) is something that should be avoided? I don't do a lot of C anymore, but even when I did, I always would do increments on separate lines, and I would do a +=1, or just a = a + 1. I never noticed a performance degradation, and I also don't think my code was harder to read. In fact I th…

I also started doing this. I feel that "b = expr(a); a++;" expresses what I mean better than "b = expr(a++)": store expr(a) in b, then store a+1 in a. Any good compiler will optimize the same. After separating a++ onto its own line, replacing a++ with a+=1 or a=a+1 comes down to personal taste in syntax sugar. I vote for a+=1.

Yeah exactly, especially for newer people.

I wouldn't be surprised if someone read `b = expr(a++)` to indicate that `a` is incremented, and then passed into `expr`, especially considering that it is within parentheses. The fact that it does it after passing it in is weird, and not obvious, at least not in my opinion. In my mind, there's no reason not to do what you suggested, or do the increment of `a` on the line before if you want the prefix.

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

#130

Post by jcalvinowens »

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…

Both major compilers yell at you for this nowadays... it's pretty unforgivable IMHO for somebody to be asking it as an exam or interview question if the right answer isn't "undefined":

    :5:10: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
        5 |     a = a++ + ++a;
          |         


    :5:7: warning: operation on 'a' may be undefined [-Wsequence-point]
        5 |     a = a++ + ++a;
          |     ~~^~~~~~~~~~~
Post reply on HN