Path: utzoo!utgpu!water!watmath!rbutterworth
From: rbutterworth@watmath.waterloo.edu (Ray Butterworth)
Newsgroups: comp.lang.c
Subject: Re: Machine specific predefined names
Message-ID: <17033@watmath.waterloo.edu>
Date: 21 Feb 88 18:12:04 GMT
References: <1988Feb17.115402.12739@light.uucp> <1988Feb21.015424.20436@utzoo.uucp>
Organization: U of Waterloo, Ontario
Lines: 55

In article <1988Feb21.015424.20436@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> while something like "open" clearly ought to be available under that
> name, it would also be nice to have it available under some implementor-
> reserved name like "__open" so that, say, "fopen" could call it without
> requiring the user to avoid using "open" as the name of one of his own
> functions.

Consider:

    #include <stdlib.h>
    #include <stdio.h>
    int open() { perror("open failed"); abort(); }
    main() { if (!fopen("xx", "r")) open(); }

Assuming I didn't make any typos, that is a correct ANSI program.
But if the ANSI fopen() uses my version of open(), it won't work
correctly.  That means the implementor of fopen() has introduced a
new reserved word, namely "open", that doesn't follow the ANSI rule
about leading underscores, and so the library is not a correct ANSI
library.

Thus the interface to the system requires something to prevent fopen()
from using my open(), and while there may be other more complicated
mechanisms, having the library use a name such as _open() internally
is obviously the simplest.

But consider a different related problem:

    #include <stdlib.h>
    #include <stdio.h>
    int putchar(int n) { abort(n); }
    main() { perror("xx"); }

Now if perror() needs putchar() to write the message, will it use
my version of putchar or an internal version, say _putchar()?

I am used to working on two different systems.  One of them uses
special entry points for all internal library calls, the other
uses no such special names.  The former would use the internal
name _putchar() in its implementation of perror(), the latter
would use the normal name putchar() in its perror().

From my point of view, the internal-name-for-everything approach
is clearly better, since a user that inadvertantly redefines an
ANSI function (especially one that won't be invented for a couple
of years yet) won't get an unpleasant surprise.  If the user
really does want to redefine a function that will be called by
the ANSI library functions, he is already doing something non=
portable and is making assumptions about how the library is
implemented.  In that case he probably already knows the internal
name of the function, and can just as easily redefine that one
instead.

I didn't see anything in the standard to indicate that either of
these behaviours is right or wrong.