Xref: utzoo comp.lang.c:32965 comp.std.c:3780 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dg!fs06!pds From: pds@lemming.webo.dg.com (Paul D. Smith) Newsgroups: comp.lang.c,comp.std.c Subject: Re: Just a minor new twist on free() Message-ID: Date: 17 Oct 90 14:24:09 GMT References: <4d5780ad.20b6d@apollo.HP.COM> <2612@van-bc.wimsey.bc.ca> Sender: root@dg.dg.com Organization: NSDD/ONAD, Data General Corp., Westboro, MA Lines: 33 In-reply-to: jtc@van-bc.wimsey.bc.ca's message of 16 Oct 90 13:40:30 GMT [] In article pds@lemming.webo.dg.com (Paul D. Smith) writes: [] >Oh no! Not that! *Never* *ever* *change* the standard libraries which [] >ship with your compiler! (unless they don't work ;-) Put it in some [] >local header file please, I don't want to change my nice, working, [] >ANSI-compliant header files in order to compile your program... [] 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. 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? -- paul ----- ------------------------------------------------------------------ | Paul D. Smith | pds@lemming.webo.dg.com | | Data General Corp. | | | Network Services Development | "Pretty Damn S..." | | Open Network Applications Department | | ------------------------------------------------------------------