🚀 go-pugleaf

In <7581@armltd.uucp> hmeekings@armltd.co.uk (Harry Meekings) writes:
>In article <1992Oct1.033932.22482@cs.aukuni.ac.nz> epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:
>>
>>void startDecode( void )
>>    {
>>    /* Initialize the bit input routines.  Since this is dual-use code
>>       we can only read in 8 bits of a possible 16 */
>>
>>    value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );
>>
>> ....
>>
>>One genuine bug.
>>
>Indeed so, but in the program not in the compiler.  The order of evaluation
>of subexpressions is unspecified (except where there's a sequence point as with
>operators such as &&).  This, by the way, is explicitly stated in K&R 1, not
>an invention of ANSI.  It so happens that the Acorn compiler in this case
>chooses to evaluate the right-hand call of fgetByte before the left-hand
>one, for reasons which have nothing to do with the optimiser.  You have been
>given one of the two values you ambiguously asked for, and can't very well
>complain.

Ahhh, I am sorry. I was sort of relying on the author of the codes appraisal
of what the compiler did to his source. He has since said that if one takes
the ANSI spec pedantically, then yes, you cannot reply on the ordering of
evaluation even when it comes to external function calls.

Makes me feel like a bit of a grumbo though :-\

That part of the HPACK source has, however, compiled on every other platform
and compiler its been ported too (= many). I am aware that ANSI-compliant
does no nessessarily == portable as there is a fair amount of detail left
up to the implementation. Maybe the documentation should point out the
more obvious departures from what the newer C programmer might expect? (I
am at least careful about post and pre increments etc...)

I shall now gracefully withdraw from the field declaring that a bug has
been found in the ANSI spec and therefore no-one around here can be
landed with responsability for the code not working... :-)

Edouard.