Turbo C++ 3.0 bugs

der Mouse mouse at Rodents.Montreal.QC.CA
Wed Dec 14 01:11:09 CST 2005


>> I met a problem in Watcom C 11.0. I uses wcl which makes 8086 code.
>> The code is running on a 386.  I got wired result with
>> printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
>> but the following code worked as expected,
>> printf("%x ", inportb(H_ADDR2));
>> printf("%x ",inportb(H_ADDR1));
>> printf("%x ", inportb(H_ADDR0));

This is a bug in the former code.

C has never guaranteed anything about the order of evaluation of the
arguments to a multi-argument call like printf; indeed, it is possible
(though unlikely in this case) that their evaluation can be overlapped.
Code that, like the single-call code, depends on that order of
evaluation is *broken*, pure and simple.  (Unless it is intended
specifically for use with a specific compiler, in which case some
degree of knowing how that compiler will compile it is not unwarranted,
though (to steal a phrase) I would call it unwarranted chumminess with
the compiler.)

> Would 'volatile'  help in this case?

Unlikely.  Even if it did, it would be a very wrong answer; depending
on this kind of compiler-specific detail is the sort of thing you
should never do until you *thoroughly* know the rules.  That the
original poster needed to ask the question at all indicates that sie
does not yet know the rules thoroughly enough to know when it's OK to
break them.  (The rule in this case is "thou shalt not depend on
implementation-defined or undefined behaviour".)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


More information about the cctalk mailing list