Re: volatile semantics

[Paul Schlie <schlie@comcast.net>]

> Gabriel Dos Reis writes:
> If by analysis, you can determine ...

The problem with this type of logic is that it leads to arbitrary
inconsistent designation of an object's reference as a function of
the breadth of the "analysis", therefore seems clearly undesirable.

Resulting in only two possibilities:

A: Treat all object references as initially declared (which isn't
   technically possible as function parameter declarations make this
   impossible to begin with, and inherently inconsistent with lvalue
   cast semantics).

B: Treat all object references as declared within their current scope,
   where the effective object declarations hierarchy looks basically
   like: <allocation-decl> [<parameter-decl> | <cast-decl>], where the
   most current represents the effective declaration of the object.

Thereby (B) represents the only tenable choice (there is no in-between).

[Which seems to be real simple to understand and abide by, regardless of
whether or not the resulting reference may specify an undefined behavior;
as the job of the compiler is to abide by the specified program, not go
out of it's way attempting to identify undefined behaviors so that it may
interject it's equally undefined inconsistent behaviors without regard to
the factual behavior that it's target would otherwise yield naturally if
it just simply warned and left well enough alone, presuming the author
desired what was specified, not something otherwise.]