From Newsgroup: comp.lang.c

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> 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?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[...]

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?

I believe I have. I'm not interested in resurrecting that old
debate. Past experience indicates that no meaningful resolution
will be reached.

I'll note that you've posted a followup to something I wrote more
than eight months ago. That's one of several reasons I'm not
interested in a discussion.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2