🚀 go-pugleaf

This essay has been written in the approximate style of some proposals
that might have been made to a committee concerned with revising the C
language standard.  The suggested proposal in this essay is inadequate
because some problems, perhaps defects, would remain in the standard's
treatment of sequence points.  The author hopes the experts in this
newsgroup might be able to improve this proposal so that it could be
suitable for submission to a committee.

The poster of this article regrets the omission of credits for some
examples and arguments that were written by other posters.  However,
no credit is possible even for the author of the proposed wording,
if the wording suggested here is adopted.  The author hopes that the
suggestions will be evaluated on their own merits.

E-mail will be ignored, with the poster's regrets.


Summary
=======
The conditions on access to an object whose value is modified between
two sequence points prevent some desirable accesses.  Present wording
also has an interpretation allowing some undesired accesses.  These
problems should be corrected.


Detailed proposal
=================
In subclause 6.3, change:

    Between the previous and next sequence point an object shall have
    its stored value modified at most once by the evaluation of an
    expression.  Furthermore, the prior value shall be accessed only
    to determine the value to be stored.

to:

    If a side effect of updating the stored value of a scalar object
    (including a scalar element or member of an aggregate) is followed
    by any access to the stored value by evaluation of an expression
    without an intervening sequence point, behavior is undefined.

In subclause 6.7.1, add:

    There is a sequence point at the start of execution of a function.


Conformance
===========
Programs that can be considered strictly conforming under an unintended
but valid interpretation of present wording, but that were not intended
to be strictly conforming, are affected by this proposal.  Programs that
were intended to be strictly conforming will either remain or become
strictly conforming, depending on the programs and interpretations.


Discussion
==========
The condition "Between the previous and next sequence point an object
shall have its stored value modified at most once by the evaluation of
an expression" yields undefined behavior for some expressions that were
intended to be permitted in a strictly conforming program.  For example:
    x[0] = x[1] = 0

However, the condition "Furthermore, the prior value shall be accessed
only to determine the value to be stored" can be interpreted as a
restriction on implementations, guaranteeing that some expressions
will access the new value with the effect of being strictly conforming,
though it was intended that such expressions yield undefined behavior.
For example, given int i = 2,
    i + i++
One reasonable interpretation is that the value of i on the left cannot
be the old value and must be 3, so that the expression has value 5.
The intention was that attempted evaluation of this expression would
yield undefined behavior.

Perversely, the latter condition yields undefined behavior for some
expressions that were intended to be possible in a strictly conforming
program.  For example, given int i = 3 and int a[5] = { 0, 1, 2, 3, 4 },
    a[a[i]] = 10
The old value of a[3] is not used in determining the value 10 and
therefore attempted evaluation of this expression yields undefined
behavior.  The intention was that this expression could be evaluated
by a strictly conforming program and that 10 be stored in a[3].

Even the expression
    i++
causes undefined behavior.  The prior value is used to determine the
result of the expression, not only to determine the value to be stored.

Furthermore, since there is no sequence point before function main()
begins executing, the expression i + i++ is allowed before the first
sequence point.  This was not intended.  Even further, no modification
occurs as a result of any expression before the first sequence point,
because subclause 6.3.16 says "The side effect of updating the stored
value of the left operand shall occur between the previous and the next
sequence point" but there is no previous sequence point.

The same defect causes a slightly different problem before the first
sequence point in a function called by qsort or bsearch.

Finally, if a side effect of updating the stored value of an object
leaves the value unchanged, it is not clear if the stored value is
considered modified.

Under the intended interpretation of the present wording, it is possible
for evaluation of an expression to happen by chance to avoid undefined
behavior, but since unlucky sequences of evaluation yield undefined
behavior, effectively the expression yields undefined behavior.  Under
the proposed wording, lucky sequences of evaluation are the opposite of
those under the present wording, but this is irrelevant.  The proposed
wording makes it unambiguous that unlucky sequences yield undefined
behavior and thus that the expression yields undefined behavior.
--****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION***
Your e-mail reply to this message WILL be *automatically* ANONYMIZED.
Please, report inappropriate use to                abuse@anon.penet.fi
For information (incl. non-anon reply) write to    help@anon.penet.fi
If you have any problems, address them to          admin@anon.penet.fi