Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!cottrell@nbs-vms.ARPA
From: cottrell@nbs-vms.ARPA
Newsgroups: net.lang.c
Subject: adr of static fns
Message-ID: <8002@brl-tgr.ARPA>
Date: Mon, 4-Feb-85 17:22:54 EST
Article-I.D.: brl-tgr.8002
Posted: Mon Feb  4 17:22:54 1985
Date-Received: Sat, 9-Feb-85 04:45:18 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 40

/*
> This is a discussion of a C semantics issue which I have not seen discussed
> on the net, or elsewhere.
> 
> The original question was, "Is it OK to take the address of a >>static<<
> function, and pass it to a separately-compiled function?"
> 
> Saying the answer is "no" appears to allow the compiler to take advantage of
> the fact to optimize the calling sequence when data flow analyses, or whatever,
> indicate that the full calling sequence is not required.
> 
> Saying the answer is "yes" means that I don't have to declare the comparison
> function used deep inside an implementation of an abstract data type to be
> external, even though its only use is to pass its address to "qsort", and it
> shouldn't be visible to any of the users of the data type.
> 
> These arguments can be presented in various other ways, which I will omit.
> 
> This problem arose practically in Version 2.0 of the Venix system for the
> IBM PC/XT, in their kludge to support large programs.  (The kludge is not
> Venturecom's fault - they have actually done a goood job of supporting large
> programs on a brain-damaged machine.)  However, they require a special form
> of call for inter-segment calls, which they do not use for static calls, since
> they are guaranteed to remain within a single segment.  This is of course only a
> special case of the optimizations which may be possible.
> 
> In reality, the answer might have to be "yes", making the Venix code in error.
> The reason is that a function may invoke another function by address. That
> function may be a static function in the same module or an external function in
> a separate module - unless the compiler gets very tricky, it will have to use
> the full calling sequence.  Therefore, optimization may only be permitted for
> functions which do not have their addresses taken.
> 
> Regardless of your views on all this, if you are really trying to write
> portable C code, don't pass the addresses of static functions around.

Why is a static funxion any different then a `regular' one? As far as I
know, all `static' does is make the name local to the file it appears in.
What am I missing?
*/