Path: utzoo!mnetor!uunet!sdrc!scjones From: scjones@sdrc.UUCP (Larry Jones) Newsgroups: comp.lang.c Subject: Re: Machine specific predefined names Message-ID: <242@sdrc.UUCP> Date: 16 Mar 88 00:09:51 GMT References: <1988Feb17.115402.12739@light.uucp> <17033@watmath.waterloo.edu> <302@wsccs.UUCP> Organization: Structural Dynamics Research Corp., Cincinnati Lines: 73 In article <302@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes: > In article <229@sdrc.UUCP>, scjones@sdrc.UUCP (Larry Jones) writes: > > In article <17033@watmath.waterloo.edu>, rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: [discussion on redefining library functions culminating in the observation that it usually works] > > I know of over 200 machines that work this way, > 120 from personal > experience. Contrary to what Larry has said, Ray, I know of no machine that > does _NOT_ work this way. Well, how fortunate you are. Try redefining putchar() like in Ray's original example some time. When the preprocessor does macro substitution on your function definition you'll get some really interesting error messages. As compilers get smarter you're going to have more and more problems with this kind of stuff and some of it can be really hairy to track down. As an example, we have our own version of the memory allocation functions (malloc, realloc, etc.) that we use for debugging - when we got a new release of the library, we discovered that if you opened a particular type of file and did a particular sequence of operations, the program would bomb. Turned out that an obscure piece of the I/O library was using the block header on the file buffer (which was know to have been malloc'ed) to determine its length. The header format had been changed and our routines were still using the old format. > I think you would be pretty safe in assuming that > _all_ machines work this way. If they don't, then piss on them. Their > manufacturers will soon find out that they have to change the behavior of > their linkers, or not have products ported to them. Sure, just take your ball and go home. Just be sure not to complain about vendors who tell you to go read the standard and refuse to change. Also, don't complain about the compile, link, and execution speed on those machines that work like you want. > I defend this position > by pointing out that while C is standard, libraries are not, and to get > portable code depending on a library function, you MUST rewrite the library > function for it to operate consitantly. Say what? If X3J11 hadn't bothered to standardize the libraries they would have been done a couple years ago. The libraries ARE standard. > For example, get 5 UNIX machines, > of any flavor, and compile and run the following fragment: > > #include > main() > { > printf( NULL); > } > > Some systems will core dump, some systems will do nothing, and others will > print the string '(NULL)' (my quotes). You get similar behaviour from things like: *(char *)0 = 5; The cause is the same - your program is WRONG. Read the draft standard and follow it and you won't have these problems. > I don't believe everybody will rewrite their UNIX in ANSI C, anyway, so lets > all hold our breath, and it will go away, leaving only K&R and some idiots > blinking their eyes at the sudden light. AT&T has stated they will provide an ANSI compiler and the POSIX standard requires one. I doubt that many vendors will supply one compiler and use a different one to compile the OS. If K&R is all you need, complete with its ambiguities, conflicts, and errors, then just go bury your head in the sand and forget about portability. No one's going to want what you're doing anyway. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."