Subject: Re: The _weirdest_ segfault...
To: None <mouse@Rodents.Montreal.QC.CA, email@example.com>
From: Ross Harvey <firstname.lastname@example.org>
Date: 05/18/2000 15:15:11
Yous see, it works like this.
A program bug is like a gunman who gets on a bus and fires three
totally random shots. Some or all of the shots may go through, say,
But since he's a program, he henceforth always fires the SAME three
random shots, so if he didn't hit any pax the first time, he won't
hit any on future bus rides, ... unless ... until ...
He get's on ANOTHER model of bus! Now, the seat spacing is
different and the same repeated shots aren't necsesarily safe.
Now, the pax themselves are armed, though some are better shots
than others. Any gunman who actually kills pax on bus model
#x86 tends to get shot by model x86 bus pax. If no one gets
hurt, tho, most pax save their ammo and don't return fire.
(The ones who notice the shots and fire back anyway are
called wizards. Don't annoy them.)
Now, if the gunman rode bus model #alpha first, and had
his random shots killed pax, the alpha pax would have
returned fire and filtered out all the actually harmful-
to-alpha pax gunmen.
But then, if he got on an #x86 bus, he might hurt someone.
I did once work at this place where a proram bug that only turned up using
one compiler (we had two) was tracked down to overrunning a malloc'ed
buffer. One programmer, a few sandwiches short of a picnic, decided that
the other compiler was better because the program didn't actually bomb when
compiled with it.
A good rule of thumb for beginning programmers is "it is never the
compiler". You can substitute for "compiler" "architecture" and/or
"OS", unless the OS is from Micro$oft. You have to be a pretty good
shot before you get to blame the compiler/OS (except M$) or the chip.
Hope this helps. :-)