Am Samstag, den 20.02.2021, 21:01 +0100 schrieb Jens Maurer:
> On 20/02/2021 13.49, Uecker, Martin wrote:
> > Am Samstag, den 20.02.2021, 12:44 +0100 schrieb Jens Maurer:
> > > 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.
>
> Yes, but that's not a good rule in my view.
>
> For example, if the function is longer, there
> might be sections of the function where the
> value can be kept in a register (because no
> address is taken in the vicinity), and the value
> is materialized into memory only around the
> place and time where/when the address is taken.
> This optimization approach seems to be precluded,
> because the value has to be put in memory
> right away (assuming a suitable architecture
> where all this matters in the first place,
> of course).

I don't understand why you think this
optimization is precluded.

> > > 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.
>
> In my view, we have a syntax-based rule in C
> that is overbroad.

Ok.

Best,
Martin