CPP(1)

📦
version 12-20220302 · 5 versions
, in ubuntu jammy

Okay bestie, this is the CPP(1) page from the GNU manual 🧚 It's all about cpp, the C preprocessor, and it's giving main character energy ✨

✨ NAME ✨

So the whole thing is cpp - The C Preprocessor 💖

🎀 SYNOPSIS 🎀

Here's the lineup of how you call it 🎀

cpp [-Dmacro[=defn]...] [-Umacro]
    [-Idir...] [-iquotedir...]
    [-M|-MM] [-MG] [-MF filename]
    [-MP] [-MQ target...]
    [-MT target...]
    infile [[-o] outfile]

These are only the most useful options, the ones that get all the love 💅 For a more complete list of preprocessor-specific options, check out the options section below. cpp also takes most gcc driver options, which aren't listed here 🫶 For those, you'll want the GCC documentation.

🌸 DESCRIPTION 🌸

The C preprocessor, aka cpp, is a macro processor. The C compiler uses it automatically to transform your program before compilation. It's called a macro processor because it lets you define macros, which are brief abbreviations for longer constructs 🦋

The C preprocessor is meant to be used only with C, C++, and Objective-C source code. In the past, people have abused it as a general text processor, and honestly, it will choke on input that doesn't follow C's lexical rules 💀 For example, apostrophes get read as the start of character constants and cause errors. You also can't count on it keeping any characteristics of the input that don't matter to C-family languages. If you preprocess a Makefile, all the hard tabs get removed, and the Makefile won't work 😭

Having said that, you can often get away with using cpp on things that aren't C 🙈 Other Algol-ish programming languages are usually safe (Ada, etc.). Assembly is also fine, but proceed with caution. -traditional-cpp mode preserves more white space and is otherwise more permissive. A lot of the problems can be avoided by writing C or C++ style comments instead of native language comments, and by keeping macros simple 🌈

Wherever possible, use a preprocessor built for the language you're writing in 👑 Modern versions of the GNU assembler have macro facilities. Most high level programming languages have their own conditional compilation and inclusion mechanisms. If all else fails, try a true general text processor, like GNU M4 🍓

C preprocessors vary a little. This manual covers the GNU C preprocessor, which gives you a small superset of the features of ISO Standard C. In its default mode, though, the GNU C preprocessor skips a few things the standard requires. These are features that are rarely, if ever, used, but they can cause surprising changes to the meaning of a program that doesn't expect them. If you want strict ISO Standard C, use -std=c90, -std=c99, -std=c11 or -std=c17, depending on which version of the standard you want. To get all the mandatory diagnostics, you also need -pedantic ⭐

Heads up: the default mode can quietly change what your program means. Use -std= plus -pedantic if you want the strict, by-the-book behavior.

This manual describes how the ISO preprocessor behaves. To cut down on gratuitous differences, the traditional preprocessor should act the same way wherever the ISO behavior doesn't clash with traditional semantics. The differences that do exist are detailed in the section Traditional Mode 🧁

For clarity, unless noted otherwise, any mention of CPP in this manual means GNU CPP 💜

💅 OPTIONS 💅

The cpp command expects two file names as arguments, infile and outfile. The preprocessor reads infile, along with any other files it pulls in with #include. All the output from the combined input files gets written to outfile ✨

Either infile or outfile can be -. As infile, it means read from standard input. As outfile, it means write to standard output. If either file is left out, it works the same as if - had been specified for that file. You can also use the -o outfile option to specify the output file 🎀

Unless noted otherwise, or the option ends in =, every option that takes an argument can have that argument right after the option, or with a space between the option and the argument. -Ifoo and -I foo do the exact same thing 🦋

Lots of options have multi-letter names, so you can't group multiple single-letter options together. -dM is very different from -d -M 🙃

  • -D name — Predefines name as a macro, with the definition 1 🌟
  • -D name=definition — The contents of definition get tokenized and processed as if they showed up during translation phase three in a #define directive. Also, the definition gets truncated by any embedded newline characters 💀
    • If you're calling the preprocessor from a shell (or something shell-like), you may need the shell's quoting syntax to protect characters like spaces, since those have meaning in shell syntax.
    • Want to define a function-like macro on the command line? Write its argument list in surrounding parentheses before the equals sign (if there is one). Parentheses mean stuff to most shells, so you should quote the option. With sh and csh, -D'name(args...)=definition' works 🧚
    • -D and -U options are processed in the order they're given on the command line. All -imacros file and -include file options get processed after all the -D and -U options.
  • -U name — Cancels any previous definition of name, whether it was built in or provided with a -D option 🙅
  • -include file — Processes file as if #include "file" appeared as the first line of the primary source file. The plot twist is that the first directory searched for file is the preprocessor's working directory, not the directory containing the main source file. If it's not found there, it gets searched for in the rest of the #include "..." search chain, like normal. If you give multiple -include options, the files get included in the order they appear on the command line 📚
  • -imacros file — Exactly like -include, except any output produced by scanning file gets thrown away. The macros it defines stay defined. This lets you grab all the macros from a header without also processing its declarations 🍓 All files specified by -imacros get processed before all files specified by -include.
  • -undef — Doesn't predefine any system-specific or GCC-specific macros. The standard predefined macros stay defined 🌸
  • -pthread — Defines the additional macros needed for using the POSIX threads library 🧵 Use this option consistently for both compilation and linking. It's supported on GNU/Linux targets, most other Unix derivatives, and also on x86 Cygwin and MinGW targets.
  • -M — Instead of outputting the result of preprocessing, outputs a rule suitable for make that describes the dependencies of the main source file. It prints one make rule containing the object file name for that source file, a colon, and the names of all the included files, including any that come from -include or -imacros command-line options 🫶
    • Unless you set it explicitly (with -MT or -MQ), the object file name is the source file's name with any suffix swapped for the object file suffix, and with any leading directory parts removed. If there are a lot of included files, the rule gets split across several lines using \-newline. The rule has no commands 💅
    • This option does not suppress the preprocessor's debug output, like -dM. To avoid mixing that debug output with the dependency rules, explicitly specify the dependency output file with -MF, or use an environment variable like DEPENDENCIES_OUTPUT. Debug output still goes to the regular output stream as normal 🙈
    • Passing -M to the driver implies -E, and suppresses warnings with an implicit -w.
  • -MM — Like -M, but doesn't mention header files found in system header directories, or header files included, directly or indirectly, from one of those headers 🦋 This also means the choice of angle brackets or double quotes in an #include directive doesn't by itself decide whether that header shows up in -MM dependency output.
  • -MF file — When used with -M or -MM, specifies a file to write the dependencies to. If there's no -MF switch, the preprocessor sends the rules to the same place it would send preprocessed output 💖 When used with the driver options -MD or -MMD, -MF overrides the default dependency output file. If file is -, the dependencies get written to stdout.
  • -MG — Used with an option like -M that requests dependency generation, -MG assumes missing header files are generated files. It adds them to the dependency list without raising an error. The dependency filename is taken straight from the #include directive, without prepending any path. -MG also suppresses preprocessed output, since a missing header file makes that useless 🌈 This feature is used for automatically updating makefiles.
  • -Mno-modules — Disables dependency generation for compiled module interfaces 🧁
  • -MP — Tells CPP to add a phony target for each dependency other than the main file, so that each one depends on nothing. These dummy rules work around the errors make gives if you remove header files without updating the Makefile to match 😭 Here's typical output:
test.o: test.c test.h

test.h:
  • -MT target — Changes the target of the rule emitted by dependency generation 🎯 By default, CPP takes the name of the main input file, deletes any directory components and any file suffix (like .c), and appends the platform's usual object suffix. That result is the target. An -MT option sets the target to be exactly the string you specify. If you want multiple targets, you can specify them as a single argument to -MT, or use multiple -MT options. For example, -MT '$(objpfx)foo.o' might give:
$(objpfx)foo.o: foo.c
  • -MQ target — Same as -MT, but it quotes any characters that are special to Make 🔥 -MQ '$(objpfx)foo.o' gives:
$$(objpfx)foo.o: foo.c

The default target is automatically quoted, as if it were given with -MQ ✨

  • -MD — -MD is equivalent to -M -MF file, except -E is not implied. The driver figures out file based on whether an -o option is given. If it is, the driver uses its argument with a .d suffix. Otherwise, it takes the name of the input file, removes any directory components and suffix, and applies a .d suffix 💜
    • If -MD is used in conjunction with -E, any -o switch is understood to specify the dependency output file. But if it's used without -E, each -o is understood to specify a target object file.
    • Since -E isn't implied, -MD can generate a dependency output file as a side effect of the compilation process 🌸
  • -MMD — okay so this is basically -MD, but it only mentions your header files and skips the system ones 🫶
  • -fpreprocessed — tells the preprocessor "hey, this file is already preprocessed, don't redo it" 💅 It skips macro expansion, trigraph conversion, escaped newline splicing, and processing of most directives. Comments still get recognized and removed, so you can pass a file preprocessed with -C to the compiler without any drama. In this mode the integrated preprocessor is literally just a tokenizer for the front ends 🧚 -fpreprocessed is implicit if the input file has one of the extensions .i, .ii or .mi, which are the extensions GCC uses for preprocessed files made by -save-temps ✨
  • -fdirectives-only — when preprocessing, it handles directives but does not expand macros 🦋 How it behaves depends on -E and -fpreprocessed:
    • With -E, preprocessing is limited to directives like #define, #ifdef, and #error. Stuff like macro expansion and trigraph conversion is not performed. Also, -dD gets implicitly enabled 🌸
    • With -fpreprocessed, predefinition of command line and most builtin macros is disabled. Contextual macros like __LINE__ are handled normally, which lets you compile files that were previously preprocessed with -E -fdirectives-only 💜
    • With both -E and -fpreprocessed, the -fpreprocessed rules take precedence. This gives you full preprocessing of files that were previously preprocessed with -E -fdirectives-only 👑
  • -fdollars-in-identifiers — accepts $ in identifiers 💖
  • -fextended-identifiers — accepts universal character names and extended characters in identifiers ✨ This is on by default for C99 (and later C standard versions) and C++ 🌈
  • -fno-canonical-system-headers — when preprocessing, it does not shorten system header paths with canonicalization 🙈
  • -fmax-include-depth=depth — sets the max depth of nested #includes. Default is 200 🧚
  • -ftabstop=width — sets the distance between tab stops 🍓 This helps the preprocessor report correct column numbers in warnings or errors, even when tabs show up on the line. If the value is less than 1 or greater than 100, the option gets ignored. Default is 8 💅
  • -ftrack-macro-expansion[=level] — tracks token locations across macro expansions 🔥 This lets the compiler show the current macro expansion stack when an error happens inside a macro expansion. Heads up: using it makes the preprocessor and the compiler eat more memory 💀 The level parameter lets you pick how precisely tokens get tracked, so you can cut memory use if you need to:
    • 0 turns this option off.
    • 1 tracks token locations in a degraded mode to keep memory overhead minimal. In this mode, every token coming out of an argument of a function-like macro has the same location.
    • 2 tracks token locations completely. This is the most memory hungry one 😭
    • If you give the option with no argument, the default level is 2.

Also, -ftrack-macro-expansion=2 is activated by default, so you're already getting the full experience 👑

  • -fmacro-prefix-map=old=new — when preprocessing files living in directory old, it expands the __FILE__ and __BASE_FILE__ macros as if the files lived in directory new instead 🦋 You can use . for new to turn an absolute path into a relative one, which can lead to more reproducible, location-independent builds 🌿 This option also affects __builtin_FILE() during compilation. See also -ffile-prefix-map.
  • -fexec-charset=charset — sets the execution character set, used for string and character constants 🌸 The default is UTF-8. charset can be any encoding supported by the system's iconv library routine.
  • -fwide-exec-charset=charset — sets the wide execution character set, used for wide string and character constants 💜 The default is UTF-32 or UTF-16, whichever matches the width of wchar_t. Same as -fexec-charset, charset can be any encoding the system's iconv routine supports, but you'll run into problems with encodings that don't fit exactly in wchar_t 😬
  • -finput-charset=charset — sets the input character set, which is used to translate from the input file's character set to the source character set GCC uses 🫧 If the locale doesn't specify one, or GCC can't get that info from the locale, the default is UTF-8. The locale or this command-line option can override it, but right now the command-line option wins if they conflict. charset can be any encoding the system's iconv library routine supports 🎀
  • -fworking-directory — turns on linemarkers in the preprocessor output so the compiler knows the current working directory at preprocessing time 🗺️ When it's on, the preprocessor emits a second linemarker after the initial one, with the current working directory followed by two slashes. GCC uses that directory, when it's in the preprocessed input, as the working directory in some debugging information formats. This option is implicitly enabled if debugging info is enabled, but you can block that with the negated form -fno-working-directory. If -P is in the command line, this option does nothing, since no #line directives get emitted whatsoever 🙅‍♀️
  • -A predicate=answer — makes an assertion with the predicate predicate and the answer answer 🧠 This form is preferred over the older -A predicate(answer) form, which still works, because it doesn't use shell special characters 🐚
  • -A -predicate=answer — cancels an assertion with the predicate predicate and the answer answer 🚫
  • -C — don't throw comments away! ✨ All comments get passed through to the output file, except comments inside processed directives, which get deleted along with the directive.
Be ready for side effects with -C. It makes the preprocessor treat comments as tokens in their own right. For example, a comment at the start of what would be a directive line turns that line into an ordinary source line, since the first token on the line is no longer a # 😭
  • -CC — don't throw comments away, even inside macro expansion 🫶 This is like -C, except comments inside macros also get passed through to the output file wherever the macro is expanded. On top of the -C side effects, -CC converts all C++-style comments inside a macro to C-style comments. This stops a later use of that macro from accidentally commenting out the rest of the source line 🙈 -CC is mostly used to support lint comments 🧹
  • -P — inhibits linemarker generation in the preprocessor output 🌙 This can be handy when you run the preprocessor on something that isn't C code and will get sent to a program that might get confused by linemarkers.
  • -traditional, -traditional-cpp — tries to imitate pre-standard C preprocessors instead of the ISO C ones 🕰️ GCC doesn't otherwise try to emulate a pre-standard C compiler, and these options only work with the -E switch or when you invoke CPP explicitly 🧚
  • -trigraphs — supports ISO C trigraphs 🔮 These are three-character sequences that all start with ??, which ISO C defines to stand for single characters. For example, ??/ stands for \, so '??/n' is a character constant for a newline 🍓 By default GCC ignores trigraphs, but in standard-conforming modes it converts them. See the -std and -ansi options.
  • -remap — enables special code to work around file systems that only allow super short file names, like MS-DOS 💾
  • -H — prints the name of each header file used, along with all the other normal stuff 📜 Each name is indented to show how deep it is in the #include stack. Precompiled header files get printed too, even if they turn out to be invalid. An invalid precompiled header gets printed with ...x, and a valid one with ...! 🔍
  • -dletters — tells GCC to make debugging dumps during compilation, based on the letters you give it 🛠️ The flags documented here are the ones relevant to the preprocessor. Other letters are interpreted by the compiler proper, reserved for future GCC versions, and silently ignored. ⚠️ If you specify letters whose behavior conflicts, the result is undefined, so please don't 🙃
    • -dM — instead of the normal output, it generates a list of #define directives for all the macros defined during preprocessing, including predefined macros. This is a great way to find out what's predefined in your version of the preprocessor 🪄 Assuming you have no file foo.h, the command touch foo.h; cpp -dM foo.h shows all the predefined macros 💅
    • -dD — like -dM, except it does not include the predefined macros, and it outputs both the #define directives and the result of preprocessing. Both kinds of output go to the standard output file 🌸
    • -dN — like -dD, but only emits the macro names, not their expansions 🫥
    • -dI — outputs #include directives in addition to the result of preprocessing 📎
    • -dU — like -dD, except only macros that get expanded, or whose definedness gets tested in preprocessor directives, are output. The output is delayed until the macro is used or tested, and #undef directives are also output for macros that were tested but undefined at that time 🦋
  • -fdebug-cpp — this one's only useful for debugging GCC 🐛 When used from CPP or with -E, it dumps debugging info about location maps. Every token in the output is preceded by the dump of the map its location belongs to. When used from GCC without -E, this option has no effect.
  • -I dir, -iquote dir, -isystem dir, -idirafter dir — adds the directory dir to the list of directories searched for header files during preprocessing 📂✨

If dir starts with = or $SYSROOT, that = or $SYSROOT gets swapped out for the sysroot prefix 🗺️. Check out --sysroot and -isysroot for the full tea.

Directories you set with -iquote only apply to the quote form of the directive, #include "file" 💌. Directories set with -I, -isystem, or -idirafter apply to lookup for both #include "file" and #include <file> 🫶.

You can stack any number or combo of these options on the command line to search a bunch of directories for header files 📚. The lookup order goes like this:

  1. For the quote form of the include directive, the directory of the current file gets searched first.
  2. For the quote form of the include directive, the -iquote directories get searched left-to-right, in the order they show up on the command line.
  3. -I directories get scanned left-to-right.
  4. -isystem directories get scanned left-to-right.
  5. Standard system directories get scanned.
  6. -idirafter directories get scanned left-to-right.

You can use -I to override a system header file and swap in your own version, since those dirs get searched before the standard system header dirs 🔁. But ngl, don't use this option to add dirs full of vendor-supplied system headers. Use -isystem for that 🚫.

The -isystem and -idirafter options also mark the directory as a system directory, so it gets the same special treatment as the standard system dirs ⭐.

If a standard system include dir, or a dir set with -isystem, is also given with -I, the -I gets ignored 🙈. The dir still gets searched, but as a system directory at its normal spot in the system include chain. This keeps GCC's procedure for fixing buggy system headers and the ordering for #include_next from getting accidentally changed. If you really need to change the search order for system dirs, use the -nostdinc and/or -isystem options.

  • -I- — Splits the include path, and it's totally deprecated 💔. Any dirs given with -I before the -I- only get searched for headers requested with #include "file", not #include <file>. Any extra -I dirs after the -I- get searched for all #include directives. On top of that, -I- stops the directory of the current file from being used as the first search dir for #include "file", and there's no way to override that effect.
Deprecated! Use -iquote instead for the -I directories that come before -I-, and then remove the -I- option.
  • -iprefix prefix — Sets prefix as the prefix for any later -iwithprefix options 🧁. If the prefix is a directory, make sure you include the final /.
  • -iwithprefix dir, -iwithprefixbefore dir — Tacks dir onto the prefix you set earlier with -iprefix, then adds the result to the include search path 🛣️. -iwithprefixbefore puts it in the same spot -I would, while -iwithprefix puts it where -idirafter would.
  • -isysroot dir — This one's like --sysroot, but it only applies to header files. The exception is Darwin targets, where it covers both header files and libraries 🍎. Check --sysroot for more deets.
  • -imultilib dir — Uses dir as a subdirectory of the directory that holds the target-specific C++ headers 🧩.
  • -nostdinc — Skips the standard system dirs when searching for header files 🙅‍♀️. Only the dirs set with -I, -iquote, -isystem, and/or -idirafter get searched, plus the directory of the current file if it's appropriate.
  • -nostdinc++ — Skips the C++-specific standard dirs, but still searches the other standard dirs 💅. (This one gets used when building the C++ library.)
  • -Wcomment, -Wcomments — Warns whenever a comment-start sequence /* shows up inside a /* comment, or whenever a backslash-newline shows up in a // comment 👀. This warning is enabled by -Wall.
  • -Wtrigraphs — Warns if any trigraphs show up that might change the meaning of the program 🔮. Trigraphs inside comments don't get warned about, except the ones that would form escaped newlines. This option is implied by -Wall. If -Wall isn't given, this option is still enabled unless trigraphs are enabled. To get trigraph conversion without the warnings, but still get the other -Wall warnings, use -trigraphs -Wall -Wno-trigraphs.
  • -Wundef — Warns if an undefined identifier gets evaluated in an #if directive. Those identifiers get replaced with zero 0️⃣.
  • -Wexpansion-to-defined — Warns whenever defined shows up in the expansion of a macro, including when an #if directive is the one expanding the macro 😬. That usage isn't portable. This warning is also enabled by -Wpedantic and -Wextra.
  • -Wunused-macros — Warns about macros defined in the main file that never get used 🧹. A macro counts as used if it gets expanded or tested for existence at least once. The preprocessor also warns if the macro hasn't been used by the time it gets redefined or undefined. Built-in macros, macros defined on the command line, and macros defined in include files don't get warned about.
Heads up: If a macro is actually used, but only in skipped conditional blocks, the preprocessor reports it as unused. To dodge the warning, you could improve the scope of the macro's definition, like moving it into the first skipped block. Or you could give it a dummy use with something like:
#if defined the_macro_causing_the_warning
#endif
  • -Wno-endif-labels — Doesn't warn when an #else or an #endif is followed by text 🏷️. This happens sometimes in older programs with code that looks like this:
#if FOO
...
#else FOO
...
#endif FOO

The second and third FOO should be in comments. This warning is on by default.

✨ ENVIRONMENT ✨

This section covers the environment variables that affect how CPP operates 🌈. You can use them to specify dirs or prefixes to search when looking for include files, or to control dependency output.

Just so you know, you can also specify places to search using options like -I, and control dependency output with options like -M. These take precedence over environment variables, which in turn take precedence over the configuration of GCC 👑.

  • CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH — Each variable's value is a list of directories separated by a special character, kinda like PATH 🧚. That special character, PATH_SEPARATOR, is target-dependent and gets decided when GCC is built. On Microsoft Windows-based targets it's a semicolon, and on almost every other target it's a colon.
    • CPATH — Specifies a list of dirs to search as if they were set with -I, but after any paths given with -I options on the command line. This env var gets used no matter which language is being preprocessed.
    • C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH — These only kick in when preprocessing their own particular language. Each one specifies a list of dirs to search as if they were set with -isystem, but after any paths given with -isystem options on the command line.
    • An empty element tells the compiler to search its current working directory 📂. Empty elements can show up at the beginning or end of a path. For instance, if the value of CPATH is ":/special/include", that has the same effect as -I. -I/special/include.
  • DEPENDENCIES_OUTPUT — If this variable is set, its value specifies how to output dependencies for Make, based on the non-system header files the compiler processes 🛠️. System header files get ignored in the dependency output. The value can be just a file name, in which case the Make rules get written to that file, with the target name guessed from the source file name. Or the value can take the form file target, in which case the rules get written to file using target as the target name. In other words, this env var is equivalent to combining the options -MM and -MF, with an optional -MT switch too.
  • SUNPRO_DEPENDENCIES — This one's the same as DEPENDENCIES_OUTPUT, except system header files aren't ignored, so it implies -M rather than -MM 🧾. However, the dependence on the main input file gets left out.
  • SOURCE_DATE_EPOCH — If this variable is set, its value specifies a UNIX timestamp to replace the current date and time in the __DATE__ and __TIME__ macros ⏰. That way the embedded timestamps stay reproducible. The value has to be a UNIX timestamp, which is defined as the number of seconds (excluding leap seconds) since 01 Jan 1970 00:00:00, represented in ASCII. It's identical to the output of date +%s on GNU/Linux and other systems that support the %s extension in the date command. The value should be a known timestamp, like the last modification time of the source or package, and it should be set by the build process 🧱.

✨ SEE ALSO ✨

gpl(7), gfdl(7), fsf-funding(7), gcc(1), and the Info entries for cpp and gcc 📖.

Copyright (c) 1987-2022 Free Software Foundation, Inc. 🗽

Permission is granted to copy, distribute and/or modify this document under the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation 📜. A copy of the license is included in the man page gfdl(7). This manual contains no Invariant Sections. The Front-Cover Texts are (a) (see below), and the Back-Cover Texts are (b) (see below).

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.

That's the whole page, bestie! 🦋 This one's from gcc-12, dated 2022-03-02, and it's the CPP(1) page. Periodt 💜✨

📦 where this page comes from