From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Quad Word Aligning of structures in linux? Date: Tue, 29 Jun 1993 02:18:40 GMT
In article <20nv6c$ssh@travis.csd.harris.com> donh@gcx1.ssd.csd.harris.com (Don Holzworth) writes:
>In article <1993Jun28.220456.23558@colorado.edu>, drew@cs.colorado.edu (Drew Eckhardt) writes:
>|> static struct {
>|> int foo;
>|> char bar;
>|> } baz __attribute__ ((aligned (16)));
>
>Is the __attribute__ a gcc thing? I've looked at my ANSI-C
>book ("C A Reference Manual" by Harbison and Steele) and can
>find no reference to it. What other __attribute__s are there
>besides aligned? Surely this would be more properly
>a pragma than a non-ANSI attribute?
Yes, __attribute__ is specific to gcc. But show me a non-gcc compiler for
Linux.
As for pragmas: the gcc info file explains this better than I can. It's
basically a question of philosophy: the authors of gcc collectively feel that
the #pragma mechnism per se is of dubious worth. Certainly the keyword method
(since the keywords have __ prefixes they are in fact legitimate, according
to the ANSI C standard) allows greater flexibility --- and doesn't force odd
line breaks to satisfy the limited recognition of #pragma. Moreover, you
can't embed a #pragma in a cpp define.
Quoting from the gcc info file, node "Function Attributes":
===============================================================================
Some people object to this feature, suggesting that ANSI C's
`#pragma' should be used instead. There are two reasons for not doing
this.
1. It is impossible to generate `#pragma' commands from a macro.
2. The `#pragma' command is just as likely as these keywords to mean
something else in another compiler.
These two reasons apply to almost any application that might be
proposed for `#pragma'. It is basically a mistake to use `#pragma' for
*anything*.
===============================================================================
I find myself in agreement with the authors of gcc on this one. #pragma is
poorly thought out and lacking in any standardization of use --- but somehow
is claimed to be "standard". Extended keywords at least are more likely to
cause a syntax error if they aren't recognized in the intended way, as opposed
to having unexpected effects.
Note also that gcc's use of such extended keywords can always be made "safe"
by means of #ifdef __GNUC__; for example, the __attribute__ example can be
made to compile (without the alignment constraint, but then there's no
portable way to do it anyway):
#ifndef __GNUC__
#define __attribute__(x)
#endif
++Brandon
-- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.orgIt's not too late to turn back from the "Gates" of Hell... Linux: the free 32-bit operating system, available NOW. Why waaaaaait for NT?