General Category > Ideas

Make increment operators statements, not expressions

(1/2) > >>

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: ---i = i++ * ++i ;  //invalid

i = v[i++];   //invalid
--- End code ---

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: ---i = (i+1) * (i+2); // or whatever the actual intention was

i = v[i];
i++;
--- End code ---

They should still be valid in the third part of a for loop, including multiple increments:

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

--- End code ---

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:

--- Quote from: bas on August 27, 2013, 12:45:58 PM ---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.
--- End quote ---


--- Code: ---i = v[i++];
i = v[i]; i++;
--- End code ---
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.


--- Quote from: bas on August 27, 2013, 12:45:58 PM ---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.
--- End quote ---

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?

Navigation

[0] Message Index

[#] Next page