RFC: first stab at getting rid of libc_hidden_proto() forest

[Joakim Tjernlund]

> -----Original Message-----
> From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On Behalf Of Carmelo Amoroso
> Sent: den 12 april 2008 07:35
> To: Denys Vlasenko
> Cc: Peter S. Mazinger; uclibc at uclibc.org
> Subject: Re: RFC: first stab at getting rid of libc_hidden_proto() forest
> 
> Denys Vlasenko wrote:
> > Hi,
> >
> > I want to make clear that I do not intend to apply this patch
> > without getting a positive review. I don't want people to
> > start thinking "omg, vda can commit this %&&$ and mess up
> > the tree"!
> >
> > I won't. It's really an RFC.
> >
> > What it does:
> >
> > I find the need of having libc_hidden_proto(fprintf)
> > anywhere you want to use fprintf efficiently (i.e.
> > to call it directly, not thru GOT/PLT) to be unmaintainable.
> >
> Hi,
> sounds reasonable...
> > First, it clogs up the source.
> >
> agree
> > Second, it's too easy to forget to do it, and you get
> > suboptimal code, silently.
> >
> agree
> > Third, sometimes it gets even more ugly: you need to know
> > _implementation details_ and dance with #defines like this:
> >
> > #ifdef __UCLIBC_HAS_XLOCALE__
> > libc_hidden_proto(__ctype_b_loc)
> > #elif __UCLIBC_HAS_CTYPE_TABLES__
> > libc_hidden_proto(__ctype_b)
> > #endif
> >
> well, this case could not be a major issue,
> it can rewritten like this
> 
> #ifdef __UCLIBC_HAS_XLOCALE__
> #define __CTYPE_B __ctype_b_loc
> #elif __UCLIBC_HAS_CTYPE_TABLES__
> #define __CTYPE_B __ctype_b
> #endif
> 
> libc_hidden_proto(__CTYPE_B)
> 
> 
> > Fifth: it needs to be repeated in every .c file where you want
> > to use e.g. ctype.h functions!
> >
> agree
> 
> > Obvious solution of adding libc_hidden_proto's to .h files
> > does not work so well since we'd like to not pollute them with
> > machinery which doesn't belong to public interface.
> >
> but we could scrub public *h at install time by removing
> all occurences of libc_hidden_proto producing a sort of
> sanitized libc headers, in the same way kernel does.
> 
> > In the attached patch, I chose to create a "master include file"
> > which includes almost all other headers; and then marks
> > all exported functions(variables) with libc_hidden_proto.
> > The file is called uClibc_libc.h.
> >
> I don't like this approach since I usually prefer explicitely
> including all specific headers are areally need, no less, no more,
> instead of a master include header.

yes, and development will hurt too as most of uClibc will need to rebuild
when adding some new feature.

> 
> This is my opinion. I agree with you about the needs of consistently
> using libc_hidden_proto, but I'd try to find another solution.
> 
> Anyway, being this a big change, I'd like to hear other opinions
> and comment.
> Mike, Jocke, Bernds, Peter others... what do you think ?

Scrubbing headers like Linux do is the best. There will probably be other
things in there too that would benefit from such scrubbing.

  Jocke