On Fri, Mar 17, 2000 at 04:28:25PM -0400, Horst von Brand wrote:
> Jakub Jelinek <jakub@redhat.com> said:
>
> [...]
>
> > Can you elaborate more on how could gcc someday decide to use an inline
> > function with completely different name?
>
> AFAIU, what your macro is supposed to be doing is:
>
> static int g(int x) { /* ... */ }
>
> int public_func(int) __alias__(("g"));
> extern inline int g(int x) { return x; }
No, it is doing something completely different:
static int g(void) { /* ... */ }
typedef int (*__init_module_func_t)(void);
int init_module(void) __attribute__((alias("g")));
extern inline __init_module_func_t __init_module_inline(void)
{ return g; }
ie. __init_module_inline function returns function pointer g.
If g's prototype does not match the __init_module_func_t type, gcc emits a
warning. And no matter whether some function actually calls
__init_module_inline or not (nobody does) gcc at least up to now takes the
function pointer taken in the unused dummy inline as a use.
> extern inline int throw_this_away(int x) { return g(x); }
>
> ? This won't protect against some lost soul defining:
>
> static double g(float x);
As I don't call the function in the dummy, but take the function pointer,
gcc will warn about some lost soul using the definition above.
>
> ...
>
> What I propose is:
>
> a) Get GCC to consider the alias as an use
Sure, but my patch shuts up the warnings even with unfixed gcc...
> b) A macro that does:
>
> int public_func(int) __alias__(("g"));
> static int g(int);
This is wrong, because this would mean you have to use static function,
which is the case in some modules and not in others.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.99-pre2 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
-
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 : Thu Mar 23 2000 - 21:00:21 EST