Re: [patch] basename vs. __gnu_basename fix

[Craig Howland <howland at LGSInnovations dot com>]

On 04/22/2015 04:00 AM, Corinna Vinschen wrote:
> On Apr 21 17:07, Craig Howland wrote:
> > On 04/21/2015 11:50 AM, Corinna Vinschen wrote:
> > > [...]
> > > +/* There are two common basename variants.  If you #include <libgen.h> you get
> > > +   the POSIX version; otherwise, if you define _GNU_SOURCE, you get the GNU
> > > +   version via <string.h>.  POSIX requires that #undef basename will still let
> > > +   you invoke the underlying function.  However, this also implies that the
> > > +   POSIX version is used in this case.  That's made sure here. */
> > > +#if __GNU_VISIBLE && !defined(basename)
> > >   char	*_EXFUN(__gnu_basename,(const char *));
> > >   # define basename __gnu_basename
> > > -# endif
> > >   #endif
> > The prototype should not be skipped if basename is defined (which I'm
> > guessing is an unintended change).
> Hang on, the prototype *must* be skipped if basename is defined.  If you
> don't do that you end up with the exact problem my patch is trying to
> fix:  You'll get two contradicting prototypes for basename, one from
> libgen.h, one from string.h.  If basename is defined, it's from
> libgen.h, so basename is already prototyped.  Have a look into the glibc
> headers.
No, the prototype is for __gnu_basename--it does not have to be skipped.  The 
only way in which it is linked to basename is when the #define is made--which 
maps basename to __gnu_basename (not vice versa).  The define must be skipped.
Craig