[patch] basename vs. __gnu_basename fix

[Craig Howland]

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