[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 9 Sep 2018 20:47:46 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: internal header proposal
On Mon, Sep 10, 2018 at 01:27:20AM +0300, Alexander Monakov wrote:
> I've written the following response a couple of days ago (before seeing your
> more recent follow-up), but it bounced due to disk space issues.
>
> On Fri, 7 Sep 2018, Rich Felker wrote:
> > Option 1: The big fancy header wrapping
>
> This looks nice to me, except ...
>
> > If we
> > wanted, at some point we could even #define the unprefixed names to
> > remap to the prefixed ones, and only #undef them in the files that
> > define them, so that everything automatically gets the namespace-safe,
> > low-call-overhead names.
>
> .... for this: I have reservations about such #defines. Preprocessing
Yes, me too. It's not something I want to do now ("at some point we
could even...") and I think there are probably good reasons not to do
it at all.
On the other hand I would potentially like to #define memcpy, memset,
etc. back to __builtin_* in string.h, just undefining them in their
respective source files, because -ffreestanding is gratuitously
pessimizing a lot of code using them. In some cases just using struct
assignments would solve the problem, but not all.
> works on a wrong level to have such redirections as general policy (e.g.
> if redirections are done via function-like macros, their effect won't
> apply when taking the address). It creates an unnecessary distraction
I had object-like macros in mind; there's no need for them to be
function-like.
> for people inspecting generated asm ("hm, where did this __ prefix came
> from?"), and I can imagine it causing problems for debugging (e.g. if
> one wanted to breakpoint on strchrnul in libc built with LTO, they'd
> be surprised to see their breakpoint didn't hit and they needed to
> breakpoint on __strchrnul instead).
Actually in this case it'd work because they're just aliases.
> > Option 2: New namespaced.h header
>
> Just want to remark that internal/libc.h already hosts a few such
> declarations, so it might make sense to either grow the kitchen sink
> further or aim to dismantle it altogether.
>
> Thank you for writing this up!
Yay, glad someone appreciates it! Sometimes I write up proposals or
documentation of development direction and get no response, and sure
it's nice to have them to look back to, but it's much nicer to have
someone reading and responding.
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.
