Just a minor new twist on free()

[J.T. Conklin]

[Followup to comp.lang.c]

In article <PDS.90Oct17102409 at lemming.webo.dg.com> pds at lemming.webo.dg.com (Paul D. Smith) writes:
>[] At UniFax, we ANSIfy the development environment on all of our
>[] development machines.  Header files get protoized and missing
>[] functions get added to the C library.
>
>I'd say all this falls under the "unless they don't work" category! :-)  
>Even so, as has already been mentioned, there are probably better ways
>of doing it than changing the standard includes.

If it can me done well, it is a definite bonus.  The source code of
your project or product can remain relatively free of #ifdef's.  I
have found that this has significantly improved maintainability.

>I have more than once been bitten by adding/changing things in the /
>and /usr directories which were shipped with the product, and having
>many things not work (I once changed the owner of /usr/bin/login to
>"bin" instead of root; now just *try* to login as anything except
>root!  And it took a whole day to discover the problem.)

>What do you do if you need to compile a program which relies on the
>old headers?

It is possible to carefully edit the standard header files to work
with both old and new behaviors; but it is inevitable that once you
have everything working, someone will do an OS upgrade and blow away
your hard work. 

Since we use gcc on most platforms, we don't convert the headers ---
we just copy everything in /usr/include into /usr/local/lib/gcc-include
and make modifications there. In this manner, the stock development
system is independent of our custom "ANSIzed" version.  Other systems
may have flags that point the compiler to look in another directory
for your header directories.

	--jtc

-- 
J.T. Conklin	UniFax Communications Inc.
		...!{uunet,ubc-cs}!van-bc!jtc, jtc at wimsey.bc.ca