bengsig@oracle.nl (Bjorn Engsig) (10/17/90)
In article <PDS.90Oct15104036@lemming.webo.dg.com> pds@lemming.webo.dg.com (Paul D. Smith) writes: |Oh no! Not that! *Never* *ever* *change* the standard libraries which |ship with your compiler! Article <2612@van-bc.wimsey.bc.ca> by jtc@van-bc.wimsey.bc.ca (J.T. Conklin) says: |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. One way to do this, if the vendors headers just miss a few things, is to create your own standard header, make the corrections necessary and #include "/usr/include/whatever.h" in this one, and use -I to get your copy included in stead of the standard one. This, of course is not at all allowed by ANSI (the headers need not even be files), but it will do the trick on most Unix systems. -- Bjorn Engsig, E-mail: bengsig@oracle.com, bengsig@oracle.nl ORACLE Corporation From IBM: auschs!ibmaus!cs.utexas.edu!uunet!oracle!bengsig "Stepping in others footsteps, doesn't bring you ahead"
chris@mimsy.umd.edu (Chris Torek) (10/18/90)
In article <PDS.90Oct15104036@lemming.webo.dg.com> pds@lemming.webo.dg.com (Paul D. Smith) writes: >>>... *Never* *ever* *change* the standard libraries which >>>ship with your compiler! In article <2612@van-bc.wimsey.bc.ca> jtc@van-bc.wimsey.bc.ca (J.T. Conklin) follows up with: >>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. In article <1020@nlsun1.oracle.nl> bengsig@oracle.nl (Bjorn Engsig) suggests: >One way to do this, if the vendors headers just miss a few things, is to >create your own standard header, make the corrections necessary and #include >"/usr/include/whatever.h" in this one, and use -I to get your copy included >instead of the standard one. We (U of MD CS department) prefer to alter the standard libraries and header files. This does require reinstalling changes with new vendor releases, although recently some of the big vendors have begun to get their acts together---SunOS and Ultrix release 4 versions (which are unrelated; they merely have the same major release number) both are much closer to ANSI conformance. There are good arguments on both sides: if you change things in `/usr/include', third-party software may suddenly manifest latent bugs and/or fail to compile, and said third parties tend to be unsympathetic when one explains that one is running a modified system. On the other hand, if you do not, third-party software may fail to compile, and they tend to be unsympathetic when one explains that one is running a non-standard-conforming system. :-) It helps a great deal to be able to point out that, although our system is not the same 4.3BSD that everyone else runs, it *is* the same, in important ways, as the Unix that others *will be* running in the near future. So I think the answer changes when one considers `ANSI Standard improvements' versus `other improvements'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris