[patch] don't give bodies for both 'extern inline' and normal versions of a function in same file

Dan Kegel dank@kegel.com
Mon Jul 19 16:03:00 GMT 2004


H. J. Lu wrote:
> On Mon, Jul 19, 2004 at 02:33:40AM -0300, Alexandre Oliva wrote:
> 
>>On Jul 18, 2004, Dan Kegel <dank@kegel.com> wrote:
>>>Similarly, with gcc-3.5, atof.c needs to avoid defining the 'extern inline'
>>>version, else gcc complains "hey, you asked for both 'always inline'
>>>and 'never inline', please figure out what you want" and aborts.
>>
>>This would be a bug in GCC.  Let's fix it there before it's released
>>instead of working around it in glibc.  extern inline is a GCC
>>extension, and this code is supposed to be accepted AFAIK.

That might be, but the comments in http://gcc.gnu.org/PR14096 leave
me with the impression that the gcc developers consider the source code
invalid, and that this is not a compiler bug.

> See
> 
> http://sources.redhat.com/ml/libc-alpha/2004-05/msg00156.html

Interesting.  It sounds like glibc will have to use 'static inline'
instead of 'extern inline' eventually, if not for gcc-3.5.

Here's the reduced preprocessed source for atof.c that causes gcc-3.5 to choke:

extern double strtod(__const char *__restrict __nptr, char **__restrict __endptr);
extern double __strtod_internal(__const char *__restrict __nptr, char
**__restrict __endptr, int __group);
extern __inline double
strtod(__const char *__restrict __nptr, char **__restrict __endptr)
{
     return __strtod_internal(__nptr, __endptr, 0);
}
extern __inline double atof(__const char *__nptr)
{
     return strtod(__nptr, (char **) ((void *) 0));
}
double atof(const char *nptr)
{
     return strtod(nptr, (char **) ((void *) 0));
}

Naively replacing 'extern' with 'static' changes the error message to
z.i:6: error: static declaration of 'strtod' follows non-static declaration
z.i:1: error: previous declaration of 'strtod' was here
z.i:14: error: redefinition of 'atof'
z.i:10: error: previous definition of 'atof' was here

The patch I posted should avoid this problem, too.
I bet you a nickel glibc will eventually apply my patch.
- Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change



More information about the Libc-alpha mailing list