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

[Jose Fonseca]

On 22/07/15 17:13, Jose Fonseca wrote:
> 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:
>
>    http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/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.
>
>
> Jose

Ironically, Windows headers already define PURE (its used in COM 
interfaces).  Just realized this now after this was merged.

So we really need a different name...

Jose