[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120215210426.2ac5d35b.idunham@lavabit.com>
Date: Wed, 15 Feb 2012 21:04:26 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: Little nit in string.h
On Wed, 15 Feb 2012 22:59:26 -0500
Rich Felker <dalias@...ifal.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@...abit.com>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
