[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.1603051756100.31711@monopod.intra.ispras.ru>
Date: Sat, 5 Mar 2016 18:13:43 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [RFC PATCH] micro-optimize __procfdname
On Sat, 5 Mar 2016, Rich Felker wrote:
> > > Actually it would be even nicer if we could use a compound literal
> > > inside the macro as the buffer, but that would pessimize with
> > > unnecessary initialization and eliminate a lot of the code-size
> > > benefit, I think.
> >
> > Yep, I did consider that and arrived to a similar conclusion. Well, there's an
> > option of using alloca as long as no use is in a loop, but that's a bit uglier,
> > and as I recall it wasn't optimized to a static stack allocation.
>
> Yeah, alloca is a lot uglier, an extra extension we don't currently
> use, and not something I would want to add.
There's an option of returning a struct containing both a buffer and a
pointer, but it's a bit worse code-size-wise and may be too magic:
struct procfdname_ret {
char *ptr, buf[procfdsize];
} __procfdname_impl(unsigned fd);
#define procfdname(fd) __procfdname_impl(fd).ptr
... and in __procfdname_impl assign a pointer to last filled position in
retval.buf to retval.ptr.
OTOH this allows further cleanup of call sites. WDYT?
Alexander
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.
