cpp.html

vxworks相关论文

<H3><A NAME="SEC12" HREF="cpp_toc.html#TOC12">Predefined Macros</A></H3>

<P>
<A NAME="IDX22"></A>
Several simple macros are predefined.  You can use them without giving
definitions for them.  They fall into two classes: standard macros and
system-specific macros.

</P>



<H4><A NAME="SEC13" HREF="cpp_toc.html#TOC13">Standard Predefined Macros</A></H4>
<P>
<A NAME="IDX23"></A>

</P>
<P>
The standard predefined macros are available with the same meanings
regardless of the machine or operating system on which you are using GNU C.
Their names all start and end with double underscores.  Those preceding
<CODE>__GNUC__</CODE> in this table are standardized by ANSI C; the rest are
GNU C extensions.

</P>
<DL COMPACT>

<DT><CODE>__FILE__</CODE>
<DD>
<A NAME="IDX24"></A>
This macro expands to the name of the current input file, in the form of
a C string constant.  The precise name returned is the one that was
specified in <SAMP>`#include'</SAMP> or as the input file name argument.

<DT><CODE>__LINE__</CODE>
<DD>
<A NAME="IDX25"></A>
This macro expands to the current input line number, in the form of a
decimal integer constant.  While we call it a predefined macro, it's
a pretty strange macro, since its "definition" changes with each
new line of source code.

This and <SAMP>`__FILE__'</SAMP> are useful in generating an error message to
report an inconsistency detected by the program; the message can state
the source line at which the inconsistency was detected.  For example,


<PRE>
fprintf (stderr, "Internal error: "
                 "negative string length "
                 "%d at %s, line %d.",
         length, __FILE__, __LINE__);
</PRE>

A <SAMP>`#include'</SAMP> directive changes the expansions of <SAMP>`__FILE__'</SAMP>
and <SAMP>`__LINE__'</SAMP> to correspond to the included file.  At the end of
that file, when processing resumes on the input file that contained
the <SAMP>`#include'</SAMP> directive, the expansions of <SAMP>`__FILE__'</SAMP> and
<SAMP>`__LINE__'</SAMP> revert to the values they had before the
<SAMP>`#include'</SAMP> (but <SAMP>`__LINE__'</SAMP> is then incremented by one as
processing moves to the line after the <SAMP>`#include'</SAMP>).

The expansions of both <SAMP>`__FILE__'</SAMP> and <SAMP>`__LINE__'</SAMP> are altered
if a <SAMP>`#line'</SAMP> directive is used.  See section <A HREF="cpp.html#SEC38">Combining Source Files</A>.

<DT><CODE>__DATE__</CODE>
<DD>
<A NAME="IDX26"></A>
This macro expands to a string constant that describes the date on
which the preprocessor is being run.  The string constant contains
eleven characters and looks like <SAMP>`"Feb  1 1996"'</SAMP>.

<DT><CODE>__TIME__</CODE>
<DD>
<A NAME="IDX27"></A>
This macro expands to a string constant that describes the time at
which the preprocessor is being run.  The string constant contains
eight characters and looks like <SAMP>`"23:59:01"'</SAMP>.

<DT><CODE>__STDC__</CODE>
<DD>
<A NAME="IDX28"></A>
This macro expands to the constant 1, to signify that this is ANSI
Standard C.  (Whether that is actually true depends on what C compiler
will operate on the output from the preprocessor.)

<DT><CODE>__STDC_VERSION__</CODE>
<DD>
<A NAME="IDX29"></A>
This macro expands to the C Standard's version number,
a long integer constant of the form <SAMP>`<VAR>yyyy</VAR><VAR>mm</VAR>L'</SAMP>
where <VAR>yyyy</VAR> and <VAR>mm</VAR> are the year and month of the Standard version.
This signifies which version of the C Standard the preprocessor conforms to.
Like <SAMP>`__STDC__'</SAMP>, whether this version number is accurate
for the entire implementation depends on what C compiler
will operate on the output from the preprocessor.

<DT><CODE>__GNUC__</CODE>
<DD>
<A NAME="IDX30"></A>
This macro is defined if and only if this is GNU C.  This macro is
defined only when the entire GNU C compiler is in use; if you invoke the
preprocessor directly, <SAMP>`__GNUC__'</SAMP> is undefined.  The value
identifies the major version number of GNU CC (<SAMP>`1'</SAMP> for GNU CC
version 1, which is now obsolete, and <SAMP>`2'</SAMP> for version 2).

<DT><CODE>__GNUC_MINOR__</CODE>
<DD>
<A NAME="IDX31"></A>
The macro contains the minor version number of the compiler.  This can
be used to work around differences between different releases of the
compiler (for example, if gcc 2.6.3 is known to support a feature, you
can test for <CODE>__GNUC__ &#62; 2 || (__GNUC__ == 2 &#38;&#38; __GNUC_MINOR__ &#62;= 6)</CODE>).
The last number, <SAMP>`3'</SAMP> in the
example above, denotes the bugfix level of the compiler; no macro
contains this value.

<DT><CODE>__GNUG__</CODE>
<DD>
<A NAME="IDX32"></A>
The GNU C compiler defines this when the compilation language is
C++; use <SAMP>`__GNUG__'</SAMP> to distinguish between GNU C and GNU
C++.

<DT><CODE>__cplusplus</CODE>
<DD>
<A NAME="IDX33"></A>
The draft ANSI standard for C++ used to require predefining this
variable.  Though it is no longer required, GNU C++ continues to define
it, as do other popular C++ compilers.  You can use <SAMP>`__cplusplus'</SAMP>
to test whether a header is compiled by a C compiler or a C++ compiler.

<DT><CODE>__STRICT_ANSI__</CODE>
<DD>
<A NAME="IDX34"></A>
This macro is defined if and only if the <SAMP>`-ansi'</SAMP> switch was
specified when GNU C was invoked.  Its definition is the null string.
This macro exists primarily to direct certain GNU header files not to
define certain traditional Unix constructs which are incompatible with
ANSI C.

<DT><CODE>__BASE_FILE__</CODE>
<DD>
<A NAME="IDX35"></A>
This macro expands to the name of the main input file, in the form
of a C string constant.  This is the source file that was specified
as an argument when the C compiler was invoked.

<DT><CODE>__INCLUDE_LEVEL__</CODE>
<DD>
<A NAME="IDX36"></A>
This macro expands to a decimal integer constant that represents the
depth of nesting in include files.  The value of this macro is
incremented on every <SAMP>`#include'</SAMP> directive and decremented at every
end of file.  For input files specified by command line arguments,
the nesting level is zero.

<DT><CODE>__VERSION__</CODE>
<DD>
<A NAME="IDX37"></A>
This macro expands to a string which describes the version number of
GNU C.  The string is normally a sequence of decimal numbers separated
by periods, such as <SAMP>`"2.6.0"'</SAMP>.  The only reasonable use of this
macro is to incorporate it into a string constant.

<DT><CODE>__OPTIMIZE__</CODE>
<DD>
<A NAME="IDX38"></A>
This macro is defined in optimizing compilations.  It causes certain
GNU header files to define alternative macro definitions for some
system library functions.  It is unwise to refer to or test the
definition of this macro unless you make very sure that programs will
execute with the same effect regardless.

<DT><CODE>__CHAR_UNSIGNED__</CODE>
<DD>
<A NAME="IDX39"></A>
This macro is defined if and only if the data type <CODE>char</CODE> is
unsigned on the target machine.  It exists to cause the standard
header file <TT>`limit.h'</TT> to work correctly.  It is bad practice
to refer to this macro yourself; instead, refer to the standard
macros defined in <TT>`limit.h'</TT>.  The preprocessor uses
this macro to determine whether or not to sign-extend large character
constants written in octal; see section <A HREF="cpp.html#SEC31">The <SAMP>`#if'</SAMP> Directive</A>.

<DT><CODE>__REGISTER_PREFIX__</CODE>
<DD>
<A NAME="IDX40"></A>
This macro expands to a string describing the prefix applied to cpu
registers in assembler code.  It can be used to write assembler code
that is usable in multiple environments.  For example, in the
<SAMP>`m68k-aout'</SAMP> environment it expands to the string <SAMP>`""'</SAMP>,
but in the <SAMP>`m68k-coff'</SAMP> environment it expands to the string
<SAMP>`"%"'</SAMP>.

<DT><CODE>__USER_LABEL_PREFIX__</CODE>
<DD>
<A NAME="IDX41"></A>
This macro expands to a string describing the prefix applied to
user generated labels in assembler code.  It can be used to write
assembler code that is usable in multiple environments.
For example, in the <SAMP>`m68k-aout'</SAMP> environment it expands to the
string <SAMP>`"_"'</SAMP>, but in the <SAMP>`m68k-coff'</SAMP> environment it expands
to the string <SAMP>`""'</SAMP>.
</DL>



<H4><A NAME="SEC14" HREF="cpp_toc.html#TOC14">Nonstandard Predefined Macros</A></H4>

<P>
The C preprocessor normally has several predefined macros that vary between
machines because their purpose is to indicate what type of system and
machine is in use.  This manual, being for all systems and machines, cannot
tell you exactly what their names are; instead, we offer a list of some
typical ones.  You can use <SAMP>`cpp -dM'</SAMP> to see the values of
predefined macros; see section <A HREF="cpp.html#SEC41">Invoking the C Preprocessor</A>.

</P>
<P>
Some nonstandard predefined macros describe the operating system in use,
with more or less specificity.  For example,

</P>
<DL COMPACT>

<DT><CODE>unix</CODE>
<DD>
<A NAME="IDX42"></A>
<SAMP>`unix'</SAMP> is normally predefined on all Unix systems.

<DT><CODE>BSD</CODE>
<DD>
<A NAME="IDX43"></A>
<SAMP>`BSD'</SAMP> is predefined on recent versions of Berkeley Unix
(perhaps only in version 4.3).
</DL>

<P>
Other nonstandard predefined macros describe the kind of CPU, with more or
less specificity.  For example,

</P>
<DL COMPACT>

<DT><CODE>vax</CODE>
<DD>
<A NAME="IDX44"></A>
<SAMP>`vax'</SAMP> is predefined on Vax computers.

<DT><CODE>mc68000</CODE>
<DD>
<A NAME="IDX45"></A>
<SAMP>`mc68000'</SAMP> is predefined on most computers whose CPU is a Motorola
68000, 68010 or 68020.

<DT><CODE>m68k</CODE>
<DD>
<A NAME="IDX46"></A>
<SAMP>`m68k'</SAMP> is also predefined on most computers whose CPU is a 68000,
68010 or 68020; however, some makers use <SAMP>`mc68000'</SAMP> and some use
<SAMP>`m68k'</SAMP>.  Some predefine both names.  What happens in GNU C
depends on the system you are using it on.

<DT><CODE>M68020</CODE>
<DD>
<A NAME="IDX47"></A>
<SAMP>`M68020'</SAMP> has been observed to be predefined on some systems that
use 68020 CPUs--in addition to <SAMP>`mc68000'</SAMP> and <SAMP>`m68k'</SAMP>, which
are less specific.

<DT><CODE>_AM29K</CODE>
<DD>
<A NAME="IDX48"></A>
<DT><CODE>_AM29000</CODE>
<DD>
<A NAME="IDX49"></A>
Both <SAMP>`_AM29K'</SAMP> and <SAMP>`_AM29000'</SAMP> are predefined for the AMD 29000
CPU family.

<DT><CODE>ns32000</CODE>
<DD>
<A NAME="IDX50"></A>
<SAMP>`ns32000'</SAMP> is predefined on computers which use the National
Semiconductor 32000 series CPU.
</DL>

<P>
Yet other nonstandard predefined macros describe the manufacturer of
the system.  For example,

</P>
<DL COMPACT>

<DT><CODE>sun</CODE>
<DD>
<A NAME="IDX51"></A>
<SAMP>`sun'</SAMP> is predefined on all models of Sun computers.

<DT><CODE>pyr</CODE>
<DD>
<A NAME="IDX52"></A>
<SAMP>`pyr'</SAMP> is predefined on all models of Pyramid computers.

<DT><CODE>sequent</CODE>
<DD>
<A NAME="IDX53"></A>
<SAMP>`sequent'</SAMP> is predefined on all models of Sequent computers.
</DL>

<P>
These predefined symbols are not only nonstandard, they are contrary to the
ANSI standard because their names do not start with underscores.
Therefore, the option <SAMP>`-ansi'</SAMP> inhibits the definition of these
symbols.

</P>
<P>
This tends to make <SAMP>`-ansi'</SAMP> useless, since many programs depend on the
customary nonstandard predefined symbols.  Even system header files check
them and will generate incorrect declarations if they do not find the names
that are expected.  You might think that the header files supplied for the
Uglix computer would not need to test what machine they are running on,
because they can simply assume it is the Uglix; but often they do, and they
do so using the customary names.  As a result, very few C programs will
compile with <SAMP>`-ansi'</SAMP>.  We intend to avoid such problems on the GNU
system.

</P>
<P>
What, then, should you do in an ANSI C program to test the type of machine
it will run on?

</P>
<P>
GNU C offers a parallel series of symbols for this purpose, whose names
are made from the customary ones by adding <SAMP>`__'</SAMP> at the beginning
and end.  Thus, the symbol <CODE>__vax__</CODE> would be available on a Vax,
and so on.

</P>
<P>
The set of nonstandard predefined names in the GNU C preprocessor is
controlled (when <CODE>cpp</CODE> is itself compiled) by the macro
<SAMP>`CPP_PREDEFINES'</SAMP>, which should be a string containing <SAMP>`-D'</SAMP>
options, separated by spaces.  For example, on the Sun 3, we use the
following definition:

</P>

<PRE>
#define CPP_PREDEFINES "-Dmc68000 -Dsun -Dunix -Dm68k"
</PRE>

<P>
This macro is usually specified in <TT>`tm.h'</TT>.

</P>


<H3><A NAME="SEC15" HREF="cpp_toc.html#TOC15">Stringification</A></H3>

<P>
<A NAME="IDX54"></A>
<EM>Stringification</EM> means turning a code fragment into a string constant
whose contents are the text for the code fragment.  For example,
stringifying <SAMP>`foo (z)'</SAMP> results in <SAMP>`"foo (z)"'</SAMP>.

</P>
<P>
In the C preprocessor, stringification is an option available when macro
arguments are substituted into the macro definition.  In the body of the
definition, when an argument name appears, the character <SAMP>`#'</SAMP> before
the name specifies stringification of the corresponding actual argument
when it is substituted at that point in the definition.  The same argument
may be substituted in other places in the definition without
stringification if the argument name appears in those places with no
<SAMP>`#'</SAMP>.

</P>
<P>
Here is an example of a macro definition that uses stringification:

</P>

<PRE>
#define WARN_IF(EXP) \
do { if (EXP) \
        fprintf (stderr, "Warning: " #EXP "\n"); } \
while (0)
</PRE>

<P>
Here the actual argument for <SAMP>`EXP'</SAMP> is substituted once as given,
into the <SAMP>`if'</SAMP> statement, and once as stringified, into the
argument to <SAMP>`fprintf'</SAMP>.  The <SAMP>`do'</SAMP> and <SAMP>`while (0)'</SAMP> are
a kludge to make it possible to write <SAMP>`WARN_IF (<VAR>arg</VAR>);'</SAMP>,
which the resemblance of <SAMP>`WARN_IF'</SAMP> to a function would make
C programmers want to do; see section <A HREF="cpp.html#SEC22">Swallowing the Semicolon</A>.

</P>
<P>
The stringification feature is limited to transforming one macro argument
into one string constant: there is no way to combine the argument with
other text and then stringify it all together.  But the example above shows
how an equivalent result can be obtained in ANSI Standard C using the
feature that adjacent string constants are concatenated as one string
constant.  The preprocessor stringifies the actual value of <SAMP>`EXP'</SAMP> 
into a separate string constant, resulting in text like

</P>

<PRE>
do { if (x == 0) \
        fprintf (stderr, "Warning: " "x == 0" "\n"); } \
while (0)
</PRE>

<P>
but the C compiler then sees three consecutive string constants and
concatenates them into one, producing effectively

</P>