Re: [RFC PATCH] micro-optimize __procfdname

[Rich Felker <dalias@libc.org>]

On Sat, Mar 05, 2016 at 09:14:57AM +0300, Alexander Monakov wrote:
> On Sat, 5 Mar 2016, Rich Felker wrote:
> > > make it really obvious that __procfdname_impl fills in reverse; it might be a
> > > very minor size optimization. I don't mind dropping this add adjusting buf
> > > with '+= procfdbufsize - 1' in the callee.
> > 
> > Yes, making it obvious what's going on is nice too.
> 
> I'm going to keep that adjustment in the macro for now, then.

OK.

> > 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.

> I forgot to ask before, shouldn't __procfdname_impl have a visibility
> annotation?
> 
> And likewise for other internal functions.  There are some internal functions
> without hidden/internal visibility annotation, visible outside of libc.so.
> That seems unintended and slightly harmful.

Yes, I'd go with only _slightly_ harmful because visibility does not
help with static linking. But of course in the static case you don't
have to worry about ABI-compat with future libc versions.

I've thought about having libc.h define a macro simply named "hidden"
for declaring things with hidden visibility; then files needing it
could just include libc.h and do stuff like:

hidden char *__procfdname_impl(...);

This would be more a matter of de-uglification than abstraction. Does
anyone particularly like or hate this idea?

Rich