There are many versions of libc, for example on this version of Linux I
am now at /lib/libc.so.6 -> libc-2.3.6.so 9a (link to)
And each version of the compiler that comes with it has its own bugs.
It is not possible with all these million lines of source to check it all.
But if you buy a transistor or chip, and it has a bug (does happen does it not),
then what do yo udo?
First, I read the datasheet and appnotes carefully for any hint of
gotchas. If we're doing anything unusual or risky or sole-sourced, we
test a few actual parts as well. If a part/mfr is deemed acceptable,
we enter that mfr and his part number into our materials database as
acceptable for purchase to satisfy out in-house part number. We know
which assemblies use each part, and can control it if, for example,
only an OnSemi part should be used on a particular assembly.
And engineers around here *only* design with approved parts. To create
a new library/inventory part, they have to get approval from the parts
czar, who happens just now to be me.
*PLUS* schematics and pcb layouts are group reviewed before release.
How many people have other people read their code?
And if _you_ think it works OK does that mean there is no bug?
Well, we test things pretty hard. If a bug does turn up, we find out
why and document the facts, and the actions to be taken, in an ECO. We
know the configuration of *every single* product in the field, and
notify users if the bug affects them.
So you jus tassume the silicon in the processor is wha tit is, and you do not
know about that near short or eroded / damaged track burried deep in the siliocon.
See, you depend on the same thing the work of others.
And those depend on _your_ feedback.
Do yo uwant to take responsibility for a defective micro?
It is all illusion.
It's no illusion that professional hardware design consistantly
produces solid products and that professional software design often
produces bloated, buggy crap. As I said, I use hardware disclipines to
produce code, and that code inherits the simplicity and reliability of
the discipline.
Software should be *more* reliable than hardware, since software has
no inherent failure modes, isn't subject to temperature changes, power
glitches, parts variability or EMI, and is precisely reproducable
times a million copies... no solder joints, no part tolerances. Yet
it's the hardware that's usually most reliable. Software is buggy
because of miserable programming methodologies and practices. Mine's
not.
This is sad: FPGA design, these days, is dominated with struggling
with the software tools, trying to get the compilers to grudgingly
agree to do what you know you want done on-chip, and then trying to
get the compilers to run to completion without crashing. See
comp.arch.fpga: it's mostly about struggling against the tools. The
FPGAs themselves - the hardware - work fine. Xilinx 9.1 is just out -
a 1.5 gig download - and SP1 is already out, another gigabyte. I
wonder if they've fixed any of the memory leaks.
John