🚀 go-pugleaf

I suggested (as one approach for dealing with broken <stdlib.h> headers):
>>         - Simply #include <stdlib.h>, and require that it be
>>           correct (by fixing or replacing the implementation if
>>           necessary).

In article <4j06k0$7s9@solutions.solon.com> Michael Smith <msmith@mpx.com.au>
writes:
>Can't agree with that.  Changing system headers is a recipe for 
>maintenance disasters.

That depends -- sometimes I am the implementor. :-)

Seriously, though, by `replacing the implementation' I meant
`returning the broken compiler, and buying a correct one from
another vendor'.  This is often possible, and is a good idea since
it exerts the most effective kind of pressure available to the
consumer.

Sometimes the real world interferes with this approach (e.g., when
the vendor has a monopoly on the supply of compilers for the CPU
in question).  In such cases, however, it usually turns out that
broken header files are the least of your worries.  Also, most of
these situations involve writing code that will never be portable
anyway (since, e.g., the 98951J is used entirely differently in
the electric mixer than in the toaster, all to save 3/10ths of a
cent per unit).

>My preferred method is to encapsulate particular subsystems where 
>portability is an issue.

Agreed.
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA	Domain:	torek@bsdi.com	+1 510 234 3167