> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carmelo Amoroso > Sent: den 12 april 2008 07:35 > To: Denys Vlasenko > Cc: Peter S. Mazinger; [email protected] > 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 _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
