[TUHS] Unix stories

[steffen@sdaoden.eu (Steffen Nurpmeso)]

Random832 <random832 at fastmail.com> wrote:
 |On Wed, Jan 4, 2017, at 08:04, Steffen Nurpmeso wrote:
 |> terrible aliasing and "sequence point" rules, where i think it is
 |> clear what i mean when i write "i = j + ++i" (i believe this is
 |> undefined behaviour).
 |
 |I assume you're imagining it as being equivalent to i = j + i + 1, with
 |a redundant store operation.
 |
 |But why couldn't it equally well mean

No i don't, and the thing is that it could definetely not equally
mean anything.  That is exactly the point.

I skip quite a lot here.
  ...
 |example is contrived too; why wouldn't you just do i += j + 1? But for a
 |better example, I was in a discussion a couple weeks ago with someone
 |who thought it was clear what they meant by an expression like this:
 |
 |*a++ = *a
 |
 |And not only was I easily able to come up with two reasonable-looking
 |implementations where it means different things, I guessed wrong on
 |which one they thought it should mean. My examples were stack-based
 |architectures with a "store to address" instruction taking operands in

So if we agree that a high level language should abstract such
problems from the programmer, with a right hand side that is
evaluated and stored in the target of the left hand side, then all
is fine.

 |each of the two possible orders, making it natural to evaluate either
 |the RHS or the address-of-LHS first. A more realistic register-based
 |architecture with pipelining might make it more efficient to evaluate
 |one or the other first, or parts of each [assuming more complex
 |expressions than in the example] mixed together, depending on the exact
 |data dependencies in both expressions.

It is all right by me.  "Can't say that on the radio."

--steffen