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 <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.
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
