Xref: utzoo comp.software-eng:2617 comp.misc:7588
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sunybcs!rutgers!att!dptg!pegasus!dmt
From: dmt@pegasus.ATT.COM (Dave Tutelman)
Newsgroups: comp.software-eng,comp.misc
Subject: Re: Coding standards (was Re: Programmer productivity)
Keywords: One function per file?
Message-ID: <4304@pegasus.ATT.COM>
Date: 6 Dec 89 13:55:16 GMT
References: <Nov.18.22.47.26.1989.9685@paul.rutgers.edu> <34796@regenmeister.uucp> <2226@jato.Jpl.Nasa.Gov> <128179@sun.Eng.Sun.COM> <546@sagpd1.UUCP> <4727@netcom.UUCP> <4290@pegasus.ATT.COM> <9185@hoptoad.uucp> <600@fred.UUCP>
Reply-To: dmt@pegasus.ATT.COM (Dave Tutelman)
Organization: AT&T Bell Labs - Lincroft, NJ
Lines: 57

>%In article <4290@pegasus.ATT.COM> dmt@pegasus.ATT.COM (Dave Tutelman) writes:
>%%There IS one argument, in some cases a compelling one, for "one function
>%%per file".  In general, linkers aren't smart enough to link just
>%%PART of a binary file (.OBJ or .o), when that file contains a function
>%%needed by the link.

>In article <9185@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>%WHAT?  What year is this?  I don't think I've ever used a linker that
>%didn't eliminate unused routines.  Any such linker would be seriously
>%brain damaged.

In article <600@fred.UUCP> bill@fred.UUCP (Bill Poitras) writes:
>Yes you have.  ANY linker you have does this.  What you are thinking of is 
>a LIBRARY, ie. .lib file. (lib*.a if you're a Unix person), which when used in
>the link process, only the functions used in the program begin linked, get 
>linked.  Although I'm not a compiler/linker expert, I almost positive that 
>this is true.

Thanks, Bill.  I generally use "dumb" linkers, though the linkers that Tim
claims to use wouldn't violate any laws of thermodynamics.  Consider:
   -	It isn't too difficult for a C compiler to demark beginning and
	end of function in a .OBJ or .o, or even just guarantee
	adjacency within a single function.  (Of course, the last function
	would have to be demarked.)
   -	The external variables (static or otherwise) ALLOCATED in that
	file could be loaded, depending on whether they are referenced
	by any of the loaded functions.

So why don't any of the linkers I use get this smart?  Because their
authors wanted to have a single linker that would handle arbitrary
object files, without depending on their being generated by their favorite
C compiler.  In particular, object files from hand-coded assembler
could also be linked in.  (This is an IMPORTANT feature of MSDOS linkers,
since a lot of programs use a little assembler for their lowest-level
routines.)

Hand-coded assembly code yields object files that CAN'T be split up
into the functions that are actually called.  Just a few of the
obvious things that make it impossible are:
   -	Self-modifying code.
   -	Gotos whose scope isn't restricted to be in the function.

This problem is solved, as Bill notes, by keeping enough information
in libraries to keep the object files separate.  If you write one
function per file, then the linker only loads the essential functions.
If you write several functions per file, then all the functions from
that file (but not all the functions in the library) get loaded if
ANY function from the file does.

When I wrote the base note, I thought about including this discussion,
but didn't because the note was long enough.  Bad decision?
+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Lincroft, NJ			|
|    Logical -  ...att!pegasus!dmt				|
|    Audible -  (201) 576 2194					|
+---------------------------------------------------------------+