Make increment operators statements, not expressions

[DerSaidin]

http://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points

Increment operators used as subexpressions (++x; x++; --x; x--) can easily produce undefined behaviour (see examples in link).

To remove this possibility, I suggest making these only appear as entire statements, not subexpressions.
This could be done by making the return type of the operators void, or by only allowing these operators as statements in the grammar.

Examples from the stackoverflow link:

Code: [Select]

i = i++ * ++i ;  //invalid

i = v[i++];   //invalid
You can argue for making these sort of issues well defined, but I think it is clearest and simplest to require the negligibly longer and perfectly explicit alternative:

Code: [Select]

i = (i+1) * (i+2); // or whatever the actual intention was

i = v[i];
i++;
They should still be valid in the third part of a for loop, including multiple increments:

Code: [Select]

for (int a=1; a<10; a++, i++)


[bas]

Nice article!
I've been programming C for around 8 years professionally, but must say I've never run into
problems like that.

What I would prefer is getting the analyser to a point where it might check for behaviour like that.
I don't think it's impossible, since it comes down to checking a variable is modified > 1 times within
a single sequence. (Standard §5/4).

So when analyser a Full expression, reset the list of modified variables. For all sub-expressions, check
whether they modify a variable that's already on the list. This would filter out all the examples given.

[DerSaidin]

I agree, I think it is something you can analyse. C compilers should probably do this and warn.

For C2, there are a few options:
a) define the behaviours
b) leave it undefined, rely on an analysis to disallow undefined behaviour
c) disallow increment as subexpressions, require explicit increment statement

I prefer c because it is the simplest and produces the clearest code.

[bas]

Yes, I think that option c would produce the clearest code. But I don't think forcing this will
help in getting C2 accepted, since it also make the code a lot bigger. There are a lot of cases
where correct usage will increase readability, because less lines of code are needed.

The balance I'm trying to find is on one side restricting the language to remove things that
are error-prone (like i = v[i++]). On the other side, not trying to restrict too much, since that
won't help convincing current C programmers to change to C2 in the future.

As a first step, maybe we could extend the FunctionAnalyser to check that no variables is changed
more then once in a single sequence?

[DerSaidin]

Yes, I think that option c would produce the clearest code. But I don't think forcing this will
help in getting C2 accepted, since it also make the code a lot bigger. There are a lot of cases
where correct usage will increase readability, because less lines of code are needed.

Code: [Select]

i = v[i++];
i = v[i]; i++;No extra lines, 3 characters bigger.

Is two statements on one line considered bad style? how is two side effects in one statement better?

Another point to consider is option c is a subset you can add to in a later version. Once there is a decent amount of C2 code you can't easily go back to option c.

The balance I'm trying to find is on one side restricting the language to remove things that
are error-prone (like i = v[i++]). On the other side, not trying to restrict too much, since that
won't help convincing current C programmers to change to C2 in the future.

That is a tricky one. C programmers like C because they don't want a language to restrict them, but the problem with C is it lets programmers make mistakes easily. The double edged sword.

This may belong in a separate thread; is C2's goal to replace C in practice?

[bas]

Well one of the starting reasons I started with C2 was the realization that:

• I was still programming C after 10 years
• There were many new language, but none that's in the domain of C
• I would probably be programming C for 10 more years

Now I like C, but some of it's quicks do feel a bit 20th century.

I don't mind making the language a bit more restricting, as it actually speeds up
development (by reducing debug time). As a rule of thumb, if the C compiler would
let you do something that all C programmers consider bad form, the C2 compiler
would just give an error.

There are a lot more ideas that can go into the language, but the idea is also not
to step outside the C domain (eg threading, garbage-collection, etc).

[kyle]

A note about this: C's macros make this problem much worse.  It is very easy to not realize that something in a macro is used twice and do this:

 foo = MY_MACRO(b[i++]);

But the macro is defined:

#define MY_MACRO(a) (a + a)

Ooops.

With the macros concept I read here (yay!), this is a lot less risky.  I personally like the idea of making it a statement to simply eliminate the practice, but it is one of the parts of the "C scripture" that might be a harder sell as Bas mentioned.  Maybe a warning is best.

Best,
Kyle