Re: calling my custom function same as library function

From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 02/28/05 

Date: 28 Feb 2005 05:17:48 GMT

In article <pP-dnfJUA9-eB7_fRVn-1A@comcast.com>,
Eric Sosman <esosman@acm-dot-org.invalid> wrote:
: Even if the linker is able to substitute a user-written
:function for an actual library function, there is no guarantee
:the program will work. Library functions may have private,
:unpublished interfaces with each other, "back doors" into each
:others' operations.

That is a good point, which is of concern with "global" linkers
that examine all the files first before choosing which function
to link to. It turns out, though, not to be a problem with
one-pass linkers unless the user explicitly names the relevant
libraries before they name their object file [and even then,
it turns out not to be a problem for the standard library.]

In one pass linkers, if the user's object file defining [say]
malloc() is placed between their other object files and the
[possibly implicit] reference to the standard C library, then
the user's definition will satisfy any malloc() references in
the user's code; the one-pass linker will then "forget" that it
has seen a definition of malloc() and will proceed onwards. When
it then encounters an unsatisfied reference to malloc() inside the
standard libraries, then it will either satisify the reference from
the same library or will look further right for the definition,
just as would normally be the case. That is, absent deliberate
manipulation to cause otherwise, user definitions of library
functions will [for one pass linkers] apply only to the user
code, and the library definition will apply for anything further
right such as the other libraries. One-pass linkers do not
do "global" replacement of function references: only
unsatisfied references to the left of the current object.

I can't speak on what happens in practice with multipass linkers.
I would, though, point out that it would be unusual for
private interfaces to exist in library functions except at file
scope, which would use internal linkage rather than external. 

-- 
How does Usenet function without a fixed point?

Relevant Pages

  • Re: Number of Objects in Static Link Library
    ... Up until this time, I've generated the libraries from object files that each represent a related group of functions and their data. ... The end result is that if a symbol in the object file is referenced, the entire object file is dragged in, even if just one function is referenced. ... With most linkers, the minimum amount that can normally be pulled in is one "module" or "translation unit". ... This normally corresponds to a single .o file that comes from either compiling a .c file or assembling an assembly-language file. ...
    (comp.unix.programmer)
  • Re: Number of Objects in Static Link Library
    ... I've generated the libraries from object files that ... result is that if a symbol in the object file is referenced, ... I'm not an expert on linkers, but as far as I know, the linker on a Unix ... compiling a .c file or assembling an assembly-language file. ...
    (comp.unix.programmer)
  • Re: Undefined references to library symbols
    ... the command line for the linking to succeed. ... Most current linkers will search all libraries, ... convention of ordering libraries from left to right. ...
    (comp.unix.programmer)
  • Re: redefinition
    ... >>Linkers don't complain much. ... Once the linker finds functA in any of the libraries, ...
    (comp.lang.c)
  • Re: undefined reference to floor()
    ... message that states undefined reference to floor. ... The math library is fairly large, and a lot of C program don't use it ... and linkers *should* be able to load only the functions that are ... and the existence of dynamic libraries probably ...
    (comp.lang.c)