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

[Jose Fonseca]

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