> [redir to gcc-help] > > On 01/01/2010 05:44 AM, Andris Kalnozols wrote: > > > If the bug was a basic programming error, one would expect a > > runtime failure (dereferencing a NULL pointer) no matter which > > compiler was used. > > I would not expect that, and I have no idea whay you would. Undefined > behaviour can happen in any way: maybe the program appears to run > correctly, maybe it faults. I stand corrected. Dumb luck was hiding a programming flaw. > > The application compiles cleanly with no warnings using "-Wall". > > Were there any transition issues with the newer gcc compilers of > > which I may not be aware? > > No. As you've done the obvious first stage (using -Wall) you now > should run your program under Valgrind, assuming that it is available > on your system. Having already looked at Valgrind a few years ago, I revisited it per your suggestion and studied its options this time. With the help of this website: https://computing.llnl.gov/code/memcheck/#deciphering4 the Valgrind application revealed this flaw: pcptr = pcptr->code = nop; "code" can't be reached through "pcptr" if the pointer does not yet have the proper address. Since multiple assignments are legal and evaluated from right to left, one could expect the following to work: pcptr->code = pcptr = nop; It does *not* work, however, using the gcc 3.3 or 4.3 compilers. To summarize: pcptr = pcptr->code = nop; /* crashes with no compiler warning */ pcptr->code = pcptr = nop; /* crashes with the warning: * operation on `pcptr' may be undefined */ pcptr->code = (pcptr = nop); /* same as above */ pcptr = nop; pcptr->code = nop; /* this works */ FWIW, the HP-UX 11.31 compiler warns/not warns in the same way but the compiled program is "luckier" at run time. Perhaps the compiler should regard the above bootstrapping-style multiple assignments as ambiguous and issue the warning regardless of the order in which the targets appear. Valgrind is an awesome tool. ------ Andris
