Am Samstag, den 20.02.2021, 12:44 +0100 schrieb Jens Maurer:
> On 20/02/2021 12.27, Uecker, Martin wrote:
> > Am Samstag, den 20.02.2021, 12:10 +0100 schrieb Jens Maurer:
> > > The "could have been declared with register" rule in C
> > > doesn't seem friendly either, because a seemingly benign
> > > no-op has spooky effects at a distance:
> > >
> > > void f()
> > > {
> > > int i;
> > >
> > > [... some lines of code...]
> > >
> > > if (false)
> > > (void)&i; // ah, address was taken, go back to the beginning of "f" and re-analyze all
> > > the
> > > code
> > > }
> >
> > Compilers need to track anyway whether the address was
> > taken so this information is readily available. Also
> > initialization and use can be at a distance, so deciding
> > whether a variable is (potentially) read before
> > initialization is a global property of a function anyway.
>
> Right, but notice that in the above example, the address
> isn't actually taken at run-time (note "if (false)"), yet
> this vacuous code appears to have semantic effect
> throughout the function.

The rule refers to a static property (could
be declared as register) and not the run-time
effect of taking the adress.

> Is there any other case
> similar to that, where non-executed syntactically
> well-formed code has an effect throughout the entire
> function? I can't think of any.

True, also I do not see why this is a problem.

I like how the rules makes many use cases just
work: In all cases where code would work
byte-wise on an object you would take the
address first. For all typical local variables
you get undefined behavior.

Best,
Marti