MSC v5.1 bug; variable not made public

Brandon S. Allbery allbery at ncoast.UUCP
Thu Nov 10 10:33:29 AEST 1988


As quoted from <792 at euraiv1.UUCP> by evas at euraiv1.UUCP (Eelco van Asperen):
+---------------
| I've just found a nice bug in MSC v5.1; if you declare an unitialized
| variable in a module that has no other publics and put that module in
| a library, the variable will _not_ be found by LINK. Here's a small
| example;
+---------------

It's not a bug.  Believe it or not, it's a feature.

The idea is to be able to load variant versions of functions based on what
is used by a program.  It applies *only* to programs.  I should note that
UN*X "ld" acts the same way (but Minix "asld" does *not*, which explains why
the following example doesn't work under Minix).

An example of why this is useful is "stdio", as implemented by UN*X and
possibly by the MSC library.  Basically, the C start-up "stub" calls the
function "main" (which is your main program function) and passes the return
value to the function "exit".  Now, IF YOU USE stdio, the exit() function
has to call another function (usually called _cleanup()) to flush stdio
buffers.  If you DON'T use stdio, the function _cleanup() must NOT be called
or stdio will be dragged into your program for no purpose and waste space.

The solution is that the linker watches for the use of multiple externs in
files in some way which I'm not really familiar with.  The effect I do
know:  if you don't reference any other stdio functions, the linker will use
the non-stdio exit().  If you reference any of the other functions, they
will force the loading of the stdio version of exit().

Your problem is that the extern variable isn't enough to force the loading
of the source file where it is declared.  When you add the function call,
it forces LINK to load the file containing it and "drags in" the extern at
the same time.  (Thus, you could have a number of different variables with
the same name declared in that way in the library, but function calling
patterns would determine which one actually got linked into the program.)

I suggest that the best place to find out about this aspect of linkers is
comp.unix.questions, since it's a question that comes up every so often
about the UN*X linker.

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery  <PREFERRED!>	    ncoast!allbery at hal.cwru.edu
allberyb at skybridge.sdi.cwru.edu	      <ALSO>		   allbery at uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.



More information about the Comp.lang.c mailing list