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

201–210 of 246 posts

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

#201

Post by chii »

adrian_b wrote: post #195
kentm wrote: post #23

Earlier quoted context omitted.

IMO, The only reasonable answer if asked this in an interview is “I would not write code where I have to know the answer to this question” These sorts of things are neat trivia to learn about things like sequence points but 99.9% of the time if it matters in your codebase you're writing something unmaintainable.

The answers to some questions must be known in order to be able to write a correct program. In the vast majority of the programming languages, the order of evaluation for the actual parameters passed to a function is undefined. In the few programming languages where the order of evaluation is defined, that is actually a mistake in the design of that programming language. This is something about which any programmer m…

> when composing function invocations it is very easy to write a function invocation where the result would depend on the order of evaluation of the expressions passed as actual parameters

this simply means your functions aren't pure functions, and is doing side effects. If you rewrite those functions to not have side effects (including ones being used to generate the parameters), there would be zero issues of such nature.

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

#203

Post by tialaramex »

thaumasiotes wrote: post #193
aidenn0 wrote: post #138

Earlier quoted context omitted.

The compiler does comply to the spec. It's the program that fails to comply with the spec. It's definitely possible to write programs that have no undefined behavior.

The compiler is supposed to compile programs that comply with the spec, and not compile programs that don't. The concept of "compiling a program that doesn't comply with the spec" doesn't even exist! A text file that doesn't comply with the C spec isn't a C program. That's what it means to be "the spec".

No, there's a fun C++ talk - by I want to say Chandler Carruth - in which the speaker points out that C++ is a language defined to have false positives for the question "Is this a valid program?"

The mechanism in the ISO document is phrases of the form "Ill-formed, No Diagnostic Required" which is often shortened to IFNDR. Lets break that down. "Ill-formed" means this is not a valid C++ program. On its own that means the compiler should provide a diagnostic (an error messag) explaining that your program isn't valid. For example if the program text were to just consist of the word "fuck" that's ill-formed and will be diagnosed. "No Diagnostic Required" says in this case though, we don't require the compiler to report this problem.

Why do that? So originally there's a purely practical reason, but ultimately there's a philosophical one. C++ like C before it wants to translate many individual program files and then somehow cobble the resulting output into a single executable. So this means function A over here, using type T from a different file cannot know for sure about type T, instead C++ has a thing called the "One Definition Rule" which says you must somewhat define T each time it's needed, but all the definitions must be the same. What if you don't (by mistake or on purpose)? Well that will cause chaos, so, IFNDR.

Philosophically IFNDR is a way to resolve the dilemma from Rice's Theorem. Back in about 1950 this guy named Henry Rice got his PhD for proving that any non-trivial semantic property of a program is Undecidable. This isn't "Oh no, it's quite hard to do this" it's a straight up mathematical proof that it can't be done. Deciding reliably whether a program has any† semantic property isn't possible. Sometimes we're sure, and that's fine, but the dilemma is for the tricky cases: What do we do when we're not sure?

IFNDR is C++ choosing "Fuck it, it's fine" for this case. Maybe your program is nonsense, it might do absolutely anything, but you don't get even a warning from the compiler. This is Chandler's "false positive".

Rust chooses the opposite. When the compiler can't see why your program is sense it will be rejected, even if you and a room full of compiler experts agree it should work too bad, it doesn't compile. You get a diagnostic explaining why your program was rejected.

† Trivial means either all programs have the property or none do and so isn't interesting. As a result the restriction to "non-trivial" properties isn't much help.

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

#204

Post by jcparkyn »

Karliss wrote: post #139
Aardwolf wrote: post #15

Earlier quoted context omitted.

But this is not valuable if doing so results in different numerical results, and I think that will always happen if ++ is executed at different times, there's no point in a compiler optimizing pointless code that can silently give different results elsewhere

The same rule which makes the evaluation order of a++ + ++a unsequenced also applies to (x+y+z+a+b+c) where x,y,z could be any expression (in a sane case on separate variables and without mix of pre/post increments). Breaking questionable code and introducing UB where reordering changes result is just a side effect of this. Just switching between left to right or right to left wouldn't be that useful but it also perm…

> If standard defined that left subexpression of addition is fully evaluated before the right expression that wouldn't be allowed.

I'm no expert, but surely this would still be allowed so long as the compiler can prove that incrementing a[0] has no effect on the value of a[1]?

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

#205

Post by tialaramex »

Dylan16807 wrote: post #198
thaumasiotes wrote: post #193

Earlier quoted context omitted.

The compiler is supposed to compile programs that comply with the spec, and not compile programs that don't. The concept of "compiling a program that doesn't comply with the spec" doesn't even exist! A text file that doesn't comply with the C spec isn't a C program. That's what it means to be "the spec".

> The concept of "compiling a program that doesn't comply with the spec" doesn't even exist! Wrong. Lots of spec violations only happen at runtime and can't be predicted at compile time. Here's an easy example. You're the compiler. I hand you what appears to be valid C code that allocates an array and then asks the user which slot to use. It doesn't verify the slot is in bounds, just puts a number in array[slot], doe…

This is "Wrong" in the sense that C++ does really work like this, but it's not wrong in the sense that this is somehow unavoidably the case.

For example if you attempt an equivalent mistake in WUFFS that will be rejected.

Your WUFFS compiler will say this variable named slot must be a non-negative integer smaller than the length of the array, but as far as it can tell you didn't ensure that was true, therefore this code is nonsense, do better.

As I explained in my sister reply, in a broader context some of these are semantic properties and so there's a dilemma and C++ chooses to resolve that dilemma by accepting nonsense programs, but that wasn't the only available resolution and I am confident it's the wrong choice.

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

#206

Post by reichstein »

alterom wrote: post #184
thaumasiotes wrote: post #113

Earlier quoted context omitted.

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

>What is the value of a spec to which compliance is impossible? Are you saying, what's the value of a language spec that allows undefined behavior , as C does? Well, it's that it allows for compiler implementations that aren't too hard to implement and maintain. It allows for a language that's close enough to hardware (and allows you to do programming on a low level), while still offering a reasonable amount of abstr…

Assigning to multiple variables in a single expression is fine and useful. Take

``` target[i++] = source1[j++] + source2[k++]; ``` That's idiomatic, it shows the intent to read and consume the value in a single expression. You can write it longer, but not more clearly.

It's only when you assign to the same variable multiple times, or read it after it was assigned, that it introduces ordering issues.

A single `i++` or `++i`/`i += 1` is safe and useful.

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

#207

Post by benj111 »

godelski wrote: post #162
tzs wrote: post #74

Earlier quoted context omitted.

> IMO, The only reasonable answer if asked this in an interview is “I would not write code where I have to know the answer to this question” That's half of a reasonable answer. The other half is "but I do know the answer so if I see it when reviewing or working on someone else's code I can flag it or rewrite it, and explain to them why it is bad".

> The other half is "but I do know the answer Except you don't! If you claim to know the answer you've made a grave mistake and fooled yourself. If you ran the code in a compiler and used that to conclude "this is the answer" rather than "this is an answer" then now is a great time to learn how easy it is to fool yourself. You just need you ask yourself what assumptions you made. I'll wager you assumed all compilers…

I think you're misinterpreting "I know the answer". The GP is suggesting rewriting it, so the know the issue.

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

#208

Post by tialaramex »

Panzerschrek wrote: post #188

That's why allowing ++ , = and += in expressions is a language design mistake. They should be statements with no possibility of result reuse. The same is for = in branch conditions and loops.

Although Rust doesn't have either ++ increment operator, it does have both the assignment = and the add-assign += and they're both expressions because almost everything in Rust is an expression.

Crucially however these expressions have the unit type () aka the empty tuple as their result, ruling out hard to follow C like int a = 1 + (b = 2 + (c = d * 3));

Similarly the "Oops I wrote = instead of ==" gets so rare as to be negligible when you stop coercing everything to a boolean. In Rust only true is true and only false is false. So when you write if k = 5 rather than checking if k == 5 that's a type error. The expression k == 5 is a boolean, that would be fine, but the expression k = 5 is just () and that's neither true nor false it's just the wrong type.

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

#209

Post by atoav »

tzs wrote: post #74
kentm wrote: post #23

Earlier quoted context omitted.

IMO, The only reasonable answer if asked this in an interview is “I would not write code where I have to know the answer to this question” These sorts of things are neat trivia to learn about things like sequence points but 99.9% of the time if it matters in your codebase you're writing something unmaintainable.

> IMO, The only reasonable answer if asked this in an interview is “I would not write code where I have to know the answer to this question” That's half of a reasonable answer. The other half is "but I do know the answer so if I see it when reviewing or working on someone else's code I can flag it or rewrite it, and explain to them why it is bad".

I mean the good answer is:

I am not sure this code could be interpreted the same by different programmers and compilers alike. So I would never write it.

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

#210

Post by alterom »

reichstein wrote: post #206
alterom wrote: post #184

Earlier quoted context omitted.

>What is the value of a spec to which compliance is impossible? Are you saying, what's the value of a language spec that allows undefined behavior , as C does? Well, it's that it allows for compiler implementations that aren't too hard to implement and maintain. It allows for a language that's close enough to hardware (and allows you to do programming on a low level), while still offering a reasonable amount of abstr…

Assigning to multiple variables in a single expression is fine and useful. Take ``` target[i++] = source1[j++] + source2[k++]; ``` That's idiomatic, it shows the intent to read and consume the value in a single expression. You can write it longer, but not more clearly. It's only when you assign to the same variable multiple times, or read it after it was assigned, that it introduces ordering issues. A single `i++` or…

>A single `i++` or `++i`/`i += 1` is safe and useful

Sure, and you don't need the assignment to be an expression with a value for it to be useful.

>target[i++] = source1[j++] + source2[k++]; That's idiomatic

That's idiomatic to C for sure.

Also idiomatically horrible. Why are you using three index variables here?

>You can write it longer, but not more clearly.

    target[i] = source1[i] + source2[i];

    i++;
This is absolutely more clear to any sane person, and less prone to error.

You can't forget to increase one if the indices when all three are meant to go in lockstep.

It's longer by one semicolon, and requires far less cognitive overload to parse.

There's a reason why they did away with it in Go. What do you think that reason was if it's so useful?

Post reply on HN