On Tue, 25 Apr 2000, Andi Kleen wrote:
>Olaf Titz <olaf@bigred.inka.de> writes:
>
>> > > static int do_something(void) {...}
>> > > EXPORT_SYMBOL(do_something);
>> > I would prefer that such a case be perfect illegal..
>>
>> Seconded.
>>
>> > It violates the Principle of Least Surprise
>>
>> Not only that, it violates longstanding C semantics.
>>
>> "static" => "can not be referenced outside this compilation unit"
>> "EXPORT_SYMBOL" => "can be referenced outside this compilation unit"
>>
>> It's simply a contradiction.
>
>The kernel just uses it everywhere.
>
>Things like that are very common all over the kernel (call it poor man's
>C++ classes):
>
>struct bla_ops {
> void (*funca)(struct bla *, int arg);
> void (*funcb)(struct bla *, int arg);
>};
>
>struct bla {
> ...
> struct bla_ops *b_ops;
>};
>
>static void my_funca(struct bla *, int arg)
>{
> ...
>}
>
>static void my_funcb(struct bla *, int arg)
>{
> ...
>}
>
>static struct bla_ops my_bla_ops = {
> funca: my_funca,
> funcb, my_funcb
>};
Note: this is a use inside the compilation unit. The storage space allocated
for two pointers to function are initialized.
>struct bla *alloc_bla(void)
>{
> struct bla *b = kmalloc(sizeof(struct bla), GFP_KERNEL);
> ...
> b->b_ops = &my_bla_ops;
> return b;
>}
And this is returning a pointer to the storage space.
>
>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.
Static symbols cannot be connected over compilation units at link time.
Static symbols don't get modified at runtime. Pointers to functions can
be modified at runtime.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
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