Path: utzoo!utgpu!water!watmath!clyde!rutgers!umd5!brl-adm!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: sizeof(function) - preproposal survey
Summary: we don't need sizeof function for that
Message-ID: <675@cresswell.quintus.UUCP>
Date: 22 Feb 88 03:42:53 GMT
References: <11801@brl-adm.ARPA> <1077@dutesta.UUCP> <395@imagine.PAWL.RPI.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 38

In article <395@imagine.PAWL.RPI.EDU>, kyriazis@pawl11.pawl.rpi.edu (George Kyriazis) writes:
>   It is *not* useless.  I wanted to get the sizeof() a function when I was
> writing a program for the PC. Concider writing device drivers and keeping
> them in a file.  The application program can then read the sizeof() the 
> function and then read() the function.  On the developers point of view having
> a sizeof(f()) option will make life a lot easier.  Write the function, debug
> it, and then compile it together with a program that gets the function's size
> and write()'s it to a file.  Any comments??
> 
Given that C is supposed to make sense on machines with separate
instruction and data space (such as some PDP-11s, the Ridge (I think),
the ICL version of the PERQ, and many many others), this doesn't seem
like something that belongs in standard C.

Having (sizeof fn) in C isn't going to help much when a function is in
several discontiguous pieces (some UNIX systems generate code in as many
as three separate chunks, which is then pasted together, but the code
for a single function may not be contiguous).  It isn't going to help
with the relocation of the function (I haven't heard the phrase
"position- independent code" in AGES, is it still fashionable?). Bearing
in mind that in some architectures, the size of an identical sequence of
symbolic instructions may depend on where they are loaded (anyone
remember page-relative addressing?)  even a contiguous function may not
HAVE a definite size.  It isn't going to help when the function requires
other functions.  There may be (I am thinking of a real case) a global
optimisation pass in the link-editor.  And so on, and so on.

We provide a dynamic loading facility in our product.  It runs under VMS
and both BSD and Missed'Em V UNIX (and other things too).  Not only did
we not need a (sizeof fn) in C to support this, we never do find out how
big a function is.  What you need is a loader which is willing to load a
file relative to an existing symbol table, and a fairly basic facility
for finding out how big the result is.  It's not the size of a function
that matters, but the size of a *file*.  

If you are using a system where this kind of operation makes sense,
you had better be able to read .obj files (or whatever they are called).
Ask the linker how big functions are, not the compiler.