|
Boost : |
From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-01-26 14:53:42
On Sun, 26 Jan 2003 12:50:13 -0500, David Abrahams
<dave_at_[hidden]> wrote:
>Gennaro Prota <gennaro_prota_at_[hidden]> writes:
>>>I am tempted to open a DR about this, but
>>>I'm not sure exactly how much we should ask for. Shooting for the
>>>moon, we could ask that an expression can only invoke undefined
>>>behavior if it is "potentially evaluated", c.f. 3.2/2
>>
>> That solves the problem when you wrap the function call in a sizeof;
>> but leaves undefined behavior for Peter's example, where the call is
>> never performed. I would say that one should allow undefined behavior
>> only if the call is actually executed (I should rather say: when the
>> call-expression is actually evaluated, to take into account inlining.
>> But I'm trying to use a simpler language).
>
>Well, that's shooting for Mars, or maybe even Pluto.
Well, only when it's nearer to Sun than Neptune. Actually IIRC this
was the situation until 1999, so maybe that should have been done
during standardization ;-)
Seriously, as far as I understand it, the actual call (in run-time) of
a function is a side-effect of the evaluation of the function-call
expression, right? If so, the choice is between
a) the behavior is undefined if it is potentially evaluated
b) the behavior is undefined if it is evaluated
[...]
>Hum. It's fine to make Peter's particular example defined, but I'm a
>little concerned about asking to lift *all* undefined behavior for
>expressions that aren't executed
Not for all expressions, just function call expressions. However
rather than speculating I think the first thing to do is to understand
what problems led the committee to decide for undefined behavior in
this case. If they are problems that take place only when the function
attempts to retrieve its arguments through va_arg then probably the
intent of the standard was already as some of us (you, me and Paul for
instance) thought it was. Otherwise the correct interpretation would
be that of Howard and there's little we can do to change it. Maybe
you, who have acquaintances, could send a mail to one of the authors
of that section ;-)
Genny.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk