Addresses of static functions

[Peter Curran]

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.