[Mesa-dev] [PATCH 1/2] mesa: Detect and provide macros for function attributes pure and const.

Jose Fonseca jfonseca at vmware.com
Wed Jul 22 09:13:08 PDT 2015

On 21/07/15 15:57, Emil Velikov wrote:
> On 18 July 2015 at 08:13, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 18/07/15 01:38, Eric Anholt wrote:
>>> Emil Velikov <emil.l.velikov at 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.

These defines are reserved for system headers, so it's natural to be 
lots of them in /usr/include.

MacOSX also defines some of these on its sys/cdefs.h:


The question is: can we expect that most systems will define these 
__foo, or at least not use them for other purposes.

I don't know the answer.  At a glance MSVC doesn't seem to rely on them 
for anything.  So it might work.  I don't oppose if you want to give it 
a shot.


More information about the mesa-dev mailing list