🚀 go-pugleaf

In article <1992Oct1.033932.22482@cs.aukuni.ac.nz>, epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:
|> I've found a bug in v4 of the Norcroft C compiler, and this time I've
|> managed to save the relevant code (unlike the first time I found a bug
|> in the compiler a few months ago--I mentioned it but had no real proof,
|> as I fixed the code before making a backup...)

[stuff deleted]

|>     value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );

[...]

|> The variable 'value' appeared to be getting the two bytes around the wrong
|> way...

This is not a bug. There is nothing in the ANSI standard which requires
function calls in an expression of this type to be evaluated in a given order.
The compiler is perfectly entitled to evaluate the second call to fgetByte
before the first one.

[Some operators *do* force an evaluation order, among them the logical
operators || and &&, so that expressions like  (a == NULL || *a == 0) make
sense.]

--
Internet: P.Hazel@ucs.cam.ac.uk       University Computing Service,
JANET:    P.Hazel@uk.ac.cam.ucs       Computer Laboratory, Pembroke St,
Phone:    +44 223 334714              Cambridge CB2 3QG, England.