--------- Received message begins Here ---------
> On Tue, Apr 25, 2000 at 06:20:45AM -0500, Jesse Pollard wrote:
> > >funca and funcb can be called from outside the module. They are still
> > >declared static. If you trust static to mean ``cannot be called from outside''
> > >you'll quickly fall flat onto your face.
> > >Overall you want a flat name space anyways, to make tools like cscope or
> > >[ce]tags work, so it is a good idea to use explicit bla_* prefixes anyways.
> > >With that static is rather useless for most cases (except special
> > >hacks like putting local symbols via macros into ELF segments etc.)
> >
> > This is not a symbolic "called from outside". sorry. does not correspond.
>
> The static functions are effectively called from outside. Who cares if
> it is symbolic or via a pointer? - the end effect counts: another unit does
> a function call and your static function is invoked. If you ignore that
> you miss a significant part of the program flow. If you trust static
> to guarantee that this does not happen you will lose.
MAJOR difference - The pointers can be changed. The sybolic reference can't.
I don't ignore that - That should be the defined (and documented) interface.
This is what allows the underpinnings to be replaced without recompiling
(and linking) an entire software system - ie kernel modules. The program
flow must be recognized as being alterable at runtime.
I only trust static to not provide symbolic addresses outside the module.
If I deliberately provide a pointer reference to another module, then I
expect that pointer to be used to call a function. If that reference
is via a structure defined local to my module, then I expect to be able
to alter those function pointers as needed.
I have seen this type of structure used to implement a state machine where each
call to a function may select a completely different function for the
next call. You can't do that with symbolic addresses. Once they are resolved,
they can't be altered.
The difference is runtime linking vs compile time linking. Normally, compile
time linking is always more efficiently done. Sometimes
flexibility/functionality wins out over efficiency. That is up to the developer.
A very HEAVY use of this capability is in X window programming. One strong
advantage is that the structure avoids generating names that may conflict
with names an application programmer uses for functions. If the name is not
a generic interface (hence static) then it is hidden from the applications
programmer. If the module that the static function is a part of proceeds to
export access to the function via a pointer, the application programmer may
not ever need to know how or even what function actually implemented the
capability. This is part of the "inheritance" of OOP as implemented by the
X window library (and yes I do find it difficult to debug).
"static" functions cannot be called from outside the module UNLESS the
module provides the address through a defined interface. It is NOT available
to be called (or cause name collision with) from other modules using the
symbolic name since the linker does not have the name.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:09 EST