4

I have been brushing up on my undefined behaviour rules, and read the following:

Undefined behavior and sequence points
Why is f(i = -1, i = -1) undefined behavior?
Why is `x-- > 0` not undefined behaviour, while `x = x--` is?

And In C++11, does `i += ++i + 1` exhibit undefined behavior?

And ended up with three questions:

  1. Do the undefined behaviour rules for terms of the form i=i++ apply to non integral types? (The expression should translate to i.operator(i.operator++(i)), and since each function call is a sequence point it should be well defined, if I understand the standard correctly)
  2. Why is f(i=-1, i=-1) undefined behaviour in combination with "The result of the assignment operation is the value stored in the left operand after the assignment has taken place; the result is an lvalue" (ref)[https://stackoverflow.com/a/4190054/258418]? (I understand that the value of i is undefined afterwards, but the functioncall should be evaluated as f(-1, -1) if I understand the standard correctly.
  3. Which types of expressions became safe with c++11/14/1z, only preincrement/predecrement in simple assignment (no op=)?
Community
  • 1
  • 1
ted
  • 4,791
  • 5
  • 38
  • 84
  • 5
    Why do all of you crazy people insist on writing such monstrosities :'( – Quentin Jul 01 '15 at 13:14
  • 1
    What do you mean by "became safe" in #3? – interjay Jul 01 '15 at 13:15
  • @Quentin: I do not insist on writing these montrosities, I will propably never go near them (I might have written something like `i=(++i)*x` instead of `i=(i+1)*x` once, but to avoid this I need a) awareness, b) be sure that the former is dangerous ( I agree that most examples are ugly/constructed). – ted Jul 01 '15 at 13:23
  • @interjay: sorry i skipped the part mentioning the new c++ standard(s) (as far as I am aware there were changes with c++11) – ted Jul 01 '15 at 13:25
  • @ted Don't worry, your question is a good one (I upvoted), I was just joking about the length of the running gag that sequence-point-triggered behaviour is becoming, even though no one would ever benefit from actually *using* such constructions :) – Quentin Jul 01 '15 at 13:27
  • Why would `f(i=-1,i=-1)` leave `i` with an undefined value? If you were assigning to different numbers, it would make sense, but since you're assigning -1 twice, shouldn't `i` end up as -1? – celticminstrel Jul 01 '15 at 13:29
  • @celticminstrel: take a look here: http://stackoverflow.com/a/21671069/258418. While unlikely o be implemented this way it would be standard conformant to my understanding. – ted Jul 01 '15 at 13:52
  • @ted #1 and #2 have already answers in the links you gived (not a direct answer for #1, but you can deduce it yourself) – Othman Benchekroun Jul 01 '15 at 13:55
  • @OthmanBenchekroun: For #2, I don;t see the answer that considers the bit of the standard cited. As for #1, you see my attempt in the question, but I am not 100% sure. – ted Jul 01 '15 at 15:03
  • @ted #2 the undefined behavior is due to the two assignments not to the call arguments – Othman Benchekroun Jul 01 '15 at 15:12
  • For #2 I think it's critical to understand that undefined behaviour is more than a undefined value. I'd see it as a property of the whole programm, it might (in theory) do anything. – Daniel Jour Jul 01 '15 at 17:17

1 Answers1

2

Forget about f (i = -1, i = -1). Assume that you have two pointers int* p and int* q, and you call

f (*p = 1, *q = 2)

This is undefined behaviour if p == q. If you don't want it to be undefined behaviour, how would you define the behaviour in the case p == q? (Because if you don't like that it's undefined, you have to define it in some way). Further, would you accept a definition of the behaviour that means 99.999% of code might run a bit slower, to save some plainly idiotic code?

Then comes the case

f (*p = -1, *q = -1)

So the same value is assigned. If you want this to be defined behaviour, but not assigning different values, how on earth to you suggest putting that into a sensible rule?

clcto
  • 9,530
  • 20
  • 42
gnasher729
  • 51,477
  • 5
  • 75
  • 98
  • I am not saying that it makes sense and we have the `restrict` keyword for the speed reason. (Where we actually pass the pointers into the function). I was more thinking that since `=` returns the value of the assignment, the function should be called with the correct arguments. I am still with you, as far as the definition of `p` and `q` for the next statement goes. – ted Jul 01 '15 at 13:34
  • @ted What do you mean ? do you want the function to be called without making the assignments ? – Othman Benchekroun Jul 01 '15 at 13:54