jacob navia wrote:
o Setup a global assignment counter that will be reset at the end
of each sequence point.

At each sequence point, not "at the end of a sequence point".
Sorry for the stupid expression above.

o Setup a global assignment counter that will be reset at the end
of each sequence point.

Consider this code:

int i;

// ...
i = i++;


I know, that's illegal.

But I am tired of answering questions like that,
so i decided to implement a warning for that kind of error.

Algorithm
---------

o Setup a global assignment counter that will be reset at the end
of each sequence point.
o For each assignment to a scalar variable store the expression
tree in an array of expressions.
If this counter contains already at least one expression, go
in a loop that:
o tests if the left hand side of the assignment is
identical to the assignment being done.
o If it is, emit a warning

It looks simple and took very little time to implement. This
makes me suspicious...

Did I forget something?

Why I have never seen a compiler that implements this
warning???

In comp.compilers.lcc Keith Thompson <kst-u at (no spam) mib.org> wrote:
jacob navia <jacob at (no spam) nospam.org> writes:
(snip)
i = i++;

I know, that's illegal.

Quibble: It's not "illegal", it's undefined behavior.

That is what they always say. Does that mean that a
compiler couldn't refuse to compile it?

In comp.compilers.lcc Keith Thompson <kst-u at (no spam) mib.org> wrote:
jacob navia <jacob at (no spam) nospam.org> writes:
(snip)
i = i++;

I know, that's illegal.

Quibble: It's not "illegal", it's undefined behavior.

That is what they always say. Does that mean that a
compiler couldn't refuse to compile it?

There are some things that are undefined or implementation
defined due to the standard allowing for ones complement
and sign magnitude integers. Sometime that is fine, other
times not.

I was trying to think if there were cases where the
undefined behavior might not be a problem.

One that doesn't work, I believe, is:

j=f(i++)+f(i++);

Where, for example, one might not care which order the
f() were called.

(snip)
Did I forget something?

Well, you can't catch all possible cases of this kind of undefined
behavior (such as ``*p = (*q)++''), but warning about the easy cases
is better than not doing so.

Not so hard to test at run time, especially if you already
have p and q in registers.

I think you're also missing cases like:

a[i++] = i;

(that's an example from the standard).

For the case with multiple i++, I understand that they
can be done in any order, and assigned back to i in
any order. In this case, I could see the assigned value
being either before or after the increment, but it is hard
to see any other value. I can imagine cases where either
would work.

or even to issue a diagnostic. In my experience, the term "illegal"
refers to constructs that the compiler is required to diagnose, or
even to reject. In C, it's not entirely unreasonable to refer to
syntax errors and constraint violations as "illegal", but I prefer to
stick to the standard's terminology to avoid confusion.

A compiler may refuse to compile it

Not unless it can prove that the undefined behavior must actually occur
at run time. Problematic code only produces undefined behavior if it's
executed and there's no license for an implementation to reject the code
just because it *might* produce undefined behavior.

In comp.std.c Keith Thompson <kst-u at (no spam) mib.org> wrote [re. undefined
behavior]:

A compiler may refuse to compile it

Not unless it can prove that the undefined behavior must actually occur
at run time. Problematic code only produces undefined behavior if it's
executed and there's no license for an implementation to reject the code
just because it *might* produce undefined behavior.

lawrence.jones at (no spam) siemens.com writes (and Gordon Burditt refuses to
acknowledge):
Not unless it can prove that the undefined behavior must actually occur
at run time. Problematic code only produces undefined behavior if it's
executed and there's no license for an implementation to reject the code
just because it *might* produce undefined behavior.

Or, the compiler could refuse to compile it if it's invoked in a
non-ANSI mode, such as gcc with -Werror combined with -Wsequence-point.

Is it forbidden for something that causes undefined behavior to
cause it at compile time? I have heard of some compilers doing
exactly that, although with stuff that must be evaluated at compile
time, like:
#if 1/0

"undefined behavior" means that the rules of the language
place no limitations on what the compiler may do.

gordonb.f0yov at (no spam) burditt.org (Gordon Burditt) writes:
Is it forbidden for something that causes undefined behavior to
cause it at compile time? I have heard of some compilers doing
exactly that, although with stuff that must be evaluated at compile
time, like:
#if 1/0

Actually that's a constraint violation.

C99 6.10.1p1 (under Constraints):

The expression that controls conditional inclusion shall be an
integer constant expression except that:
[...]

C99 6.6p4 (under Constraints):

Each constant expression shall evaluate to a constant that is in
the range of representable values for its type.

(Permission to quote my words without proper attribution is denied.)

jacob navia <jacob at (no spam) nospam.org> writes:
Consider this code:

int i;

// ...
i = i++;


I know, that's illegal.

Quibble: It's not "illegal", it's undefined behavior.