On Tue, 09.03.10 22:12, Balbir Singh ([email protected]) wrote: > * Lennart Poettering <[email protected]> [2010-03-09 16:58:12]:
> > libcg is Linux-specific anyway. AC_USE_SYSTEM_EXTENSIONS enables the > > full Linux API. Every single API call there is on Linux. And for > > something that is Linux-specific anyway, this should be the exact right > > thing to do. > > > > There is no bloat due to header expansion, namespace collision issues, > etc? Does it make sense to enable things like _TANDEM_SOURCE, etc? No. There should not be a problem with that. those #ifdefs are nops on Linux. Thre should not be any namespace issues. And if there were it should be left to the autoconf folks to fix them so that A_U_S_E can be used without headache. Also, an #ifdef like this does not influence in any way how you link your stuff, so it should have exactly no runtime effect. If you really are concerned about issues like this, as least use the older AC_GNU_SOURCE, wich sets _GNU_SOURCE only. But then again, I'd always go for A_U_S_E simply because I wouldn't want to create the impression that anything of this was really specific to glibc. Because it isn't. it is specific to Linux. And for weirdos who want to link your libs against non-glibc libc's it might be quite handy if your code isn't bound to GNU, but simply to the functions you actually need. If you understand what I mean. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
