[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 25 Jul 2012 13:35:24 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 9/10] GLIBC ABI patches
On Wed, Jul 25, 2012 at 05:52:46PM +0200, Luca Barbato wrote:
> > I think the idea is that we might want to use __strndup internally in
> > functions which can't expose the strndup name. However, as we haven't
> > yet had a need for that, I suspect it's unlikely. Also, __strndup
> > isn't really an ugly name (it makes sense as the "internal" name for
> > strndup if such usage were needed), but __isoc99_scanf is a huge WTF
> > unless you know the reason it exists in glibc (and then it just makes
> > you hate glibc even more...).
>
> Would be nice make all those alias consistent, might be interesting see
> if linker scripts could be use for similar purposes, keeping the core
> code cleaner.
Considering that the linker is never run on the static library that
would be rather difficult. Even if it were possible, I think it would
just subtract a trivial amount of cruft that's easy to ignore from the
.c files at the expense of making the build system much uglier and
more GNU-binutils-dependent.
If lots of people think it's confusing having a mix of aliases that
are for internal/legitimate purposes and for ugly ABI purposes, I
either add comments to all the ABI-only ones that they can be ignored
by somebody reading the source, or I could do something like the LFS64
macros and have a separate macro for the ABI-only aliases that would
be self-documenting of their purpose and that could be nulled out by
extremists who want them gone...
Rich
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.
