Path: utzoo!attcan!uunet!husc6!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: portability
Message-ID: <9467@smoke.BRL.MIL>
Date: 21 Jan 89 14:26:38 GMT
References: <16573@iuvax.cs.indiana.edu> <9419@smoke.BRL.MIL> <86097@sun.uucp> <877@auspex.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <877@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>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"...

I believe they plan something along those lines, but it's important
to note that it isn't really necessary to augment the linker in order
to meet the ANSI C constraints; the C library can contain entries for
both _write and write, with the standard C functions using only the
former.  The most significant drawback to the scheme is that both the
C library and traditional programs that use write() and standard I/O
will increase in size if there is actually redundant code with two
names.  If it weren't for the recent use of "random archive" tables
of contents, but instead libraries were sequentially searched as in
good old original UNIX, then the additional size could also be
avoided using existing linkers by arranging for a 0-length module
containing the "write" entry point occur immediately before the one
with the code labeled "_write".