Machine specific predefined names

[Larry Jones]

In article <302 at wsccs.UUCP>, terry at wsccs.UUCP (terry) writes:
> In article <229 at sdrc.UUCP>, scjones at sdrc.UUCP (Larry Jones) writes:
> > In article <17033 at watmath.waterloo.edu>, rbutterworth at 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 <stdio.h>
> 	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."