Little nit in string.h

Little nit in string.h

[Isaac Dunham]

basename (string.h:88) should accept a "const char *", instead of "char *"
(this is breaking the build for some libiberty versions)

I noticed this trying to build gcc-3.4.6-1 (because gcc3 is faster and doesn't do the completely wrong optimizations of gcc4).

-- 
Isaac Dunham <idunham@lavabit.com>

Re: Little nit in string.h

[Rich Felker]

On Wed, Feb 15, 2012 at 07:47:27PM -0800, Isaac Dunham wrote:
> basename (string.h:88) should accept a "const char *", instead of "char *"
> (this is breaking the build for some libiberty versions)
> 
> I noticed this trying to build gcc-3.4.6-1 (because gcc3 is faster
> and doesn't do the completely wrong optimizations of gcc4).

Unfortunately this software is expecting the GNU version of basename,
whose prototype does not match the standard function (defined in
libgen.h). If libiberty is trying to define basename itself, I wonder
if the CFLAGS at configure and build time are mismatching in a way
that makes it think it needs to do this. I don't see any solution to
the problem by changing the headers, since putting a wrong prototype
in string.h would conflict with the correct version in libgen.h if
both are included. Maybe we could get away with a non-prototype
declaration in string.h, though, i.e. just:

char *basename();

Ideas welcome.

Rich

Re: Little nit in string.h

[Isaac Dunham]

On Wed, 15 Feb 2012 22:59:26 -0500
Rich Felker <dalias@aerifal.cx> wrote:

> On Wed, Feb 15, 2012 at 07:47:27PM -0800, Isaac Dunham wrote:
> > basename (string.h:88) should accept a "const char *", instead of "char *"
> > (this is breaking the build for some libiberty versions)
> > 
> Unfortunately this software is expecting the GNU version of basename,
> whose prototype does not match the standard function (defined in
> libgen.h). If libiberty is trying to define basename itself, I wonder
> if the CFLAGS at configure and build time are mismatching in a way
> that makes it think it needs to do this. I don't see any solution to
> the problem by changing the headers, since putting a wrong prototype
> in string.h would conflict with the correct version in libgen.h if
> both are included. Maybe we could get away with a non-prototype
> declaration in string.h, though, i.e. just:
> 
> char *basename();

libiberty is declaring it as an extern, if __linux__ or any other indicator of a FOSS libc (OpenBSD, GNU Libc, Cygwin...) is detected.
Yes, I know this is completely wrong and insane (as is most of the GNU approach).

basename in string.h is guarded by _GNU_SOURCE (in both musl & glibc), so if you don't define that, musl/glibc would still work fine.  If you define it, include string.h, and then include libgen.h, it certainly won't work with glibc; currently musl would accept that.

It would be possible to  
#undef basename
in libgen.h, but I don't like that idea. 

-- 
Isaac Dunham <idunham@lavabit.com>

Re: Little nit in string.h

[Rich Felker]

On Wed, Feb 15, 2012 at 09:04:26PM -0800, Isaac Dunham wrote:
> libiberty is declaring it as an extern, if __linux__ or any other
> indicator of a FOSS libc (OpenBSD, GNU Libc, Cygwin...) is detected.
> Yes, I know this is completely wrong and insane (as is most of the
> GNU approach).

Yes, this is completely wrong, and the only solution I see is the one
I suggested (the non-prototype declaration).

> basename in string.h is guarded by _GNU_SOURCE (in both musl &
> glibc), so if you don't define that, musl/glibc would still work
> fine. If you define it, include string.h, and then include libgen.h,
> it certainly won't work with glibc; currently musl would accept
> that.

You mean if you included both in libiberty? It certainly works to
include both in other programs using glibc as long as those programs
don't declare their own basename...

> It would be possible to  
> #undef basename
> in libgen.h, but I don't like that idea. 

I don't quite follow..

Rich