portability

[Ray Butterworth]

In article <877 at auspex.UUCP>, guy at auspex.UUCP (Guy Harris) writes:
> > Does _flsbuf need to be rewritten to call __write() or
> >something similar
> Yes.
> >where __write is implemented as:
> No.  What I think AT&T plans to do for S5R4, for example, is to *rename*
> the "write" routine "_write", and have a mechanism by which the linker
> will let "_write" satisfy unresolved references for "write" (or
> something like that); this means programs that call "write" and expect
> it to be the "write" in the system library will not have to be changed -
> but neither will programs that have their own private "write".

It seems to me that every implementor of a library other than
the Standard C library is going to need a means of having
alternate names for its functions (unless none of them call
each other).  If not, it means that for anyone using part of
a large library all the identifiers in the library become
reserved words that he must be aware of.

Thus, unless one wants to have library source that look like:
    write(args) { return __write(args); }
    __write(args) { implementation of normal write function }
and have all user calls carry double the calling overhead,
every compiler writer is going to have to come up with a
mechanism for doing this aliasing.  And every library implementor
(unless he also controls the compiler) is going to be out of luck.
At least I, as a library implementor, don't know of any nice way
of doing this without making changes to the compiler.

I don't understand why the C Standard didn't require, or at least
suggest, some such standard mechanism.

e.g.
    write(args) entry __write { c_blah c_blah }
i.e. the resulting assembly code should look something like:
    write:
    __write:
        a_blah
        a_blah