From: tr.17687@z991.linuxsc.com

Keith Thompson  writes:

> Tim Rentsch  writes:
>
>> Keith Thompson  writes:
>>
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>> [...]
>>>
>>>> Well, it is rather easy to see if variable is used within its
>>>> own initialization, so practically it is minor gap.  Of course,
>>>> there is problem with C standard:  IIUC depending on rest of
>>>> the code declarations as above are merely undefined behaviour
>>>> or even produce unspecified value.  So C compiler is
>>>> forbidden to stop compilation are report compile time error.
>>>
>>> Valid responses to undefined behavior include "terminating a translation
>>> or execution (with the issuance of a diagnostic message)".
>>
>> That's true, but doing so is allowed only if the circumstances
>> of undefined behavior have occurred.  In the case of compiling
>> a declaration such as
>>
>>     int a = a;
>>
>> no undefined behavior has as yet occurred.
>
> N3096 6.3.2.1p2 (lvalue conversion):
>
>     If the lvalue designates an object of automatic storage duration
>     that could have been declared with the register storage class (never
>     had its address taken), and that object is uninitialized (not
>     declared with an initializer and no assignment to it has been
>     performed prior to use), the behavior is undefined.
>
> Strictly speaking, `a` doesn't meet the definition of
> "uninitialized", since it is declared with an initializer, but
> its value is accessed before the initialization has been executed.
> I'm not entirely certain that `int a = a;` has undefined behavior,
> but it's unclear that the behavior is defined.

Clearly the term "uninitialized" is meant to refer to a dynamic
property, not a static property.  At the point on the right side
of the '=' where the access is performed, the object designated
by 'a' has not been initialized.

>>> In other
>>> words, if a compiler is able to prove that a program has undefined
>>> behavior (that will occur on each execution), it can reject it at
>>> compile time.
>>
>> The program can be rejected, but not because of the rule about
>> terminating a translation.  The program can be rejected because
>> the program is not strictly conforming, and implementations are
>> not required to accept programs that are not strictly conforming.
>
> I disagree, but we've gone over this before with no resolution.

Have you ever offered reasoning to explain your belief, or
did you give just an unsupported conclusion?  Can you explain
the reasoning that underlies your disagreement?

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)