type-attributes.html

自己收集的linux入门到学懂高级编程书集 包括linux程序设计第三版

     <pre class="smallexample">          struct my_unpacked_struct
           {
              char c;
              int i;
           };
          
          struct my_packed_struct __attribute__ ((__packed__))
            {
               char c;
               int  i;
               struct my_unpacked_struct s;
            };
          </pre>

     <p>You may only specify this attribute on the definition of a <code>enum</code>,
<code>struct</code> or <code>union</code>, not on a <code>typedef</code> which does not
also define the enumerated type, structure or union.

     <br><dt><code>transparent_union</code>
     <dd>This attribute, attached to a <code>union</code> type definition, indicates
that any function parameter having that union type causes calls to that
function to be treated in a special way.

     <p>First, the argument corresponding to a transparent union type can be of
any type in the union; no cast is required.  Also, if the union contains
a pointer type, the corresponding argument can be a null pointer
constant or a void pointer expression; and if the union contains a void
pointer type, the corresponding argument can be any pointer expression. 
If the union member type is a pointer, qualifiers like <code>const</code> on
the referenced type must be respected, just as with normal pointer
conversions.

     <p>Second, the argument is passed to the function using the calling
conventions of the first member of the transparent union, not the calling
conventions of the union itself.  All members of the union must have the
same machine representation; this is necessary for this argument passing
to work properly.

     <p>Transparent unions are designed for library functions that have multiple
interfaces for compatibility reasons.  For example, suppose the
<code>wait</code> function must accept either a value of type <code>int *</code> to
comply with Posix, or a value of type <code>union wait *</code> to comply with
the 4.1BSD interface.  If <code>wait</code>'s parameter were <code>void *</code>,
<code>wait</code> would accept both kinds of arguments, but it would also
accept any other pointer type and this would make argument type checking
less useful.  Instead, <code>&lt;sys/wait.h&gt;</code> might define the interface
as follows:

     <pre class="smallexample">          typedef union
            {
              int *__ip;
              union wait *__up;
            } wait_status_ptr_t __attribute__ ((__transparent_union__));
          
          pid_t wait (wait_status_ptr_t);
          </pre>

     <p>This interface allows either <code>int *</code> or <code>union wait *</code>
arguments to be passed, using the <code>int *</code> calling convention. 
The program can call <code>wait</code> with arguments of either type:

     <pre class="smallexample">          int w1 () { int w; return wait (&amp;w); }
          int w2 () { union wait w; return wait (&amp;w); }
          </pre>

     <p>With this interface, <code>wait</code>'s implementation might look like this:

     <pre class="smallexample">          pid_t wait (wait_status_ptr_t p)
          {
            return waitpid (-1, p.__ip, 0);
          }
          </pre>

     <br><dt><code>unused</code>
     <dd>When attached to a type (including a <code>union</code> or a <code>struct</code>),
this attribute means that variables of that type are meant to appear
possibly unused.  GCC will not produce a warning for any variables of
that type, even if the variable appears to do nothing.  This is often
the case with lock or thread classes, which are usually defined and then
not referenced, but contain constructors and destructors that have
nontrivial bookkeeping functions.

     <br><dt><code>deprecated</code>
     <dd>The <code>deprecated</code> attribute results in a warning if the type
is used anywhere in the source file.  This is useful when identifying
types that are expected to be removed in a future version of a program. 
If possible, the warning also includes the location of the declaration
of the deprecated type, to enable users to easily find further
information about why the type is deprecated, or what they should do
instead.  Note that the warnings only occur for uses and then only
if the type is being applied to an identifier that itself is not being
declared as deprecated.

     <pre class="smallexample">          typedef int T1 __attribute__ ((deprecated));
          T1 x;
          typedef T1 T2;
          T2 y;
          typedef T1 T3 __attribute__ ((deprecated));
          T3 z __attribute__ ((deprecated));
          </pre>

     <p>results in a warning on line 2 and 3 but not lines 4, 5, or 6.  No
warning is issued for line 4 because T2 is not explicitly
deprecated.  Line 5 has no warning because T3 is explicitly
deprecated.  Similarly for line 6.

     <p>The <code>deprecated</code> attribute can also be used for functions and
variables (see <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>, see <a href="Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>.)

     <br><dt><code>may_alias</code>
     <dd>Accesses to objects with types with this attribute are not subjected to
type-based alias analysis, but are instead assumed to be able to alias
any other type of objects, just like the <code>char</code> type.  See
<code>-fstrict-aliasing</code> for more information on aliasing issues.

     <p>Example of use:

     <pre class="smallexample">          typedef short __attribute__((__may_alias__)) short_a;
          
          int
          main (void)
          {
            int a = 0x12345678;
            short_a *b = (short_a *) &amp;a;
          
            b[1] = 0;
          
            if (a == 0x12345678)
              abort();
          
            exit(0);
          }
          </pre>

     <p>If you replaced <code>short_a</code> with <code>short</code> in the variable
declaration, the above program would abort when compiled with
<code>-fstrict-aliasing</code>, which is on by default at <code>-O2</code> or
above in recent GCC versions.

<h3 class="subsection">i386 Type Attributes</h4>

     <p>Two attributes are currently defined for i386 configurations:
<code>ms_struct</code> and <code>gcc_struct</code>

     <br><dt><code>ms_struct</code>
     <dd><dt><code>gcc_struct</code>
     <dd>

     <p>If <code>packed</code> is used on a structure, or if bit-fields are used
it may be that the Microsoft ABI packs them differently
than GCC would normally pack them.  Particularly when moving packed
data between functions compiled with GCC and the native Microsoft compiler
(either via function call or as data in a file), it may be necessary to access
either format.

     <p>Currently <code>-m[no-]ms-bitfields</code> is provided for the Microsoft Windows X86
compilers to match the native Microsoft compiler. 
</dl>

   <p>To specify multiple attributes, separate them by commas within the
double parentheses: for example, <code>__attribute__ ((aligned (16),
packed))</code>.

   </body></html>