Ijust sent a post that agrees so thoroughly with what you just wrote that
we even both used the same reference to Holub!
--
Grumpy Ol' Fred ci...@xenosoft.com
On Thu, 15 Aug 2024, Mike Katz wrote:
Fred,
That is true, Order of expression is undefined between execution points that
is why the following statement can produce different results on different
compilers:
A = 1;
F = A++ * A++;
Without the use of parenthesis the is no way for the user to know beforehand
what the value of F will be. The only guarantee is that when the before the
next instruction is executed the all postfix operators will be evaluated
prior to the start of the next C statement.
As a general rule rvalue expressions are calculated by the pre-compiler and
not the compiler. So the line:
ulDays = ulSeconds / ( 60 * 60 * 24 );
Would be converted by the precompiler to:
ulDay = ulSeconds / 86400;
The calculation of the lvalue ulSeconds / 86400 will be handled at run time.
However, if ulSeconds is defined as a const it is possible that a smart
precompiler will do the entire calculation and only the assignment will be
done at runtime.
It is possible that the volatile keyword might cause the order of expression
to be altered.
uint32_t * volatile ulpDMAAddress = 0xffff0000; // Note this is a volatile
pointer and NOT a pointer to volatile data.
uint32_t *ulpMyPointer;
ulpMyPointer = *ulpDMAAddress++ + *ulpDMAAddress++;
My mind is getting numb just looking at that code. Suffice it to say that
using multiple prefix/postfix operations in a single execution point is
heavily deprecated because the actual results are implementation defined and
my even be different depending upon what other math surrounds it.
Another implementation specific feature of C is the order of bits in bit
fields. They can be assigned from most significant to least significant or
vice-versa. It is totally up to the compiler.
As Allan Holub says C and C++, in his book of the same name, gives the
programmer "Enough Rope To Shoot Yourself in the Foot"
On 8/15/2024 6:45 PM, Fred Cisin via cctalk wrote:
It is not the hardware that is at fault.
If anybody else is to blame, it is the compiler.
On Thu, 15 Aug 2024, Paul Koning wrote:
More likely the language designers, assuming the compiler doesn't have a
standards violation in its code. In the case of C, the type promotion
rules that were just explained are rather bizarre and surprising. Other
languages do it differently, with perhaps fewer surprises. Some define
it very carefully (ALGOL 68 comes to mind), some not so much.
C very explicitly leaves some thing undefined, supposedly to work with more
machines, and Kernighan & Ritchie say that it is the responsibility of the
programmer to create unambiguous code.
for example, evaluation of expressions in the lvalue might be done before
OR after evaluation of expressions in th rvalue
Some other languages are much stricter on types, etc. and have fewer
ambiguities.
