[TUHS] Unix stories

[random832@fastmail.com (Random832)]

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
i = 0; i += j; i+= ++i
i = 0; i += j; i += (i += 1)

If an architecture were to the most efficient way to assign an additive
expression to a variable to zero it out and add each successive operand
to it.

The example seems contrived, because it's honestly hard to make a
reasonable-sounding case for the prefix operators, and my usual go-to
examples require postfix operators and/or pointers. But to be fair, your
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
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.

> Explicit instrumentation via new language constructs would require
> more man power than paying a standard gremium to define semantics
> which effectively allow more compiler optimization and gain more
> performance and thus a sellable catchphrase, but on the long term
> this surely soils the ground on which we stand.
> 
> I for one maintain a codebase that has grown over now almost four
> decades and i still cannot say i stand on grounds of pureness,
> beauty and elegance; attributes which, were possible, brighten up
> everydays work and make a day.
> 
> --steffen