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

[Emil Velikov]

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.

Thanks
Emil