This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Mar 5 2012, George Bosilca wrote:
> I was afraid about all those little intermediary steps. I asked a
> compiler guy and apparently reversing the order (aka starting with the
> ptrdiff_t variable) will not solve anything. The only portable way to
> solve this is to cast every single member, to prevent __any__ compiler
> from hurting us.
That is true, but even that may not help, given that each version of
the C standard has been incompatible with its predecessors. And see
>> In my copy of C99, section 6.5 Expressions says " the order of
>> evaluation of subexpressions and the order in which side effects take
>> place are both unspecified. There is a footnote 71 that "specifies the
>> precedence of operators in the evaluation of an expressions, which is
>> the same as the order of the major subclauses of this subclause, highest
>> precedence first." It is the footnote that implies multiplication (6.5.5
>> Multiplicative operators) has higher precedence than addition (6.5.6
>> Additive operators) in the expression "(char*) rbuf + rank * rcount *
>> rext". But, the main text states that there is no ordering of the
>> subexpression "rank * rcount * rext". When the compiler chooses to
>> evaluate "rank * rcount" first, the overflow described by Yuki can
>> result. I think you are correct that the subexpression will get promoted
>> to (ptrdiff_t), but that is not quite the same thing.
No, it's not as simple as that :-(
That was the intent during the standardisation of C90, but those of
us who tried failed to get any explicit statement into it, and the
situation during C99 was that "but everybody knows that" the syntax
rules also define the evaluation order. We failed to get that stated
then, either :-( That interpretation was apparently also the one
assumed by C++03, too, and now is explicitly (if informally) stated in
C++11. So you theoretically can just cast the first operand to the
maximum precision and it will all work.
What it means by the "order of evaluation of subexpressions" is that
the assignments in '(a = b) + (c = d) + (e = f)' can take place in
any order, which is a different issue.
HOWEVER, about half of the C communities have given C99 the thumbs
down, I doubt that C11 will be taken much notice of, gcc is the
de facto standard definer, and most compilers have optimisation
options that say "ignore the standard when it helps to go faster".
So the only feasible rule is to do your damnedest to defend yourself
against the aberrations, ambiguities and inconsistencies of C, and
hope for the best. I.e. what George recommends.
But will even that work reliably in the medium term? I wouldn't
bet on it :-(