16 Aug
2024
16 Aug
'24
12:38 a.m.
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 cisin(a)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.
>