On 18 July 2015 at 08:13, Jose Fonseca <jfons...@vmware.com> wrote: > On 18/07/15 01:38, Eric Anholt wrote: >> >> Emil Velikov <emil.l.veli...@gmail.com> writes: >> >>> On 14/07/15 19:45, Eric Anholt wrote: >>>> >>>> These are really useful hints to the compiler in the absence of >>>> link-time >>>> optimization, and I'm going to use them in VC4. >>>> >>>> I've made the const attribute be ATTRIBUTE_CONST unlike other function >>>> attributes, because we have other things in the tree #defining CONST for >>>> their own unrelated purposes. >>> >>> Mindly related: how people feel about making these macros less screamy, >>> by following the approach used in the kernel: PURE -> __pure and so on ? >> >> >> I'd love it. > > > Less screamy is fine, but beware prefixing double underscore: the C standard > stipulates that its use is reserved for for C/C++ runtime. [1] > I though about it before posting although I've seen others define those, even do so in their public headers. Now that I have some examples from my current /usr/include
Searching for __pure dwarves/dutil.h:#define __pure __attribute__ ((pure)) Searching for __attribute_const__ sys/cdefs.h:# define __attribute_const__ __attribute__ ((__const__)) sys/cdefs.h:# define __attribute_const__ /* Ignore */ Searching for __printf Searching for __always_unused Searching for __noreturn Searching for __packed libvisual-0.4/libvisual/lv_defines.h:# define __packed __attribute__ ((packed)) libvisual-0.4/libvisual/lv_defines.h:# define __packed /* no packed */ bsd/sys/cdefs.h:# define __packed __attribute__((__packed__)) bsd/sys/cdefs.h:# define __packed Searching for __deprecated pciaccess.h:#define __deprecated __attribute__((deprecated)) pciaccess.h:#define __deprecated Searching for __weak Searching for __alias With a handful of other headers defining more double underscore prefixed macros. > Look at stdlibc++ implementation: every internal variable has a double > underscore prefix. > Unless we're talking about STL/other template library we don't care what library foo uses in it's internal implementation do we ? After all these will be resolved at compile time. > Maybe kernel gets away on GLIBC (and because it doesn't use C++), but > there's no guarantee it will work on other C runtimes, and even if it does, > it could start failing anytime. > True, it's not the best of ideas. Just worth pointing out that "the cat is already out", for other projects. There are already more than 12K "#define __foo" cases on my system. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
