CPP(1)

πŸ“¦
version 10.5.0 Β· 3 versions
, in ubuntu noble

πŸ’– cpp: The C Preprocessor (GNU) πŸ’–

section 1 · part 1 of 3 ✨

✨ NAME ✨

cpp - The C Preprocessor 🌸


πŸŽ€ SYNOPSIS πŸŽ€

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

okay so these are only the most useful options bestie 🫢 there's a more complete list of preprocessor-specific options further down. cpp also takes most gcc driver options, but those aren't listed here, so check the GCC docs for the details πŸ“š.


πŸ¦‹ DESCRIPTION πŸ¦‹

okay so the C preprocessor, aka cpp, is a macro processor that the C compiler runs automatically to transform your program before compilation ✨. It's called a macro processor bc 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 πŸ‘‘. People have abused it as a general text processor in the past πŸ’€, and it will choke on input that doesn't follow C's lexical rules. Like, apostrophes get read as the start of character constants and cause errors 😭. You also can't count on it keeping characteristics of the input that don't matter to C-family languages. If a Makefile gets preprocessed, all the hard tabs get removed and the Makefile won't work πŸ™ˆ.

🚨 Heads up bestie: if you run a Makefile through cpp, every hard tab gets stripped out and the Makefile will NOT work. Not cute πŸ’€.

Having said that, you can often get away with using cpp on stuff that isn't C 🌈. Other Algol-ish programming languages are usually safe (Ada, etc.) 🧚. Assembly is also fine, but 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 your macros simple πŸ’–.

Wherever possible, use a preprocessor geared to 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 mechanism 🌸. If all else fails, try a true general text processor, like GNU M4 πŸ’œ.

C preprocessors vary a bit in the details πŸŽ€. This manual is about the GNU C preprocessor, which gives you a small superset of the features of ISO Standard C ✨. In its default mode, it 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 πŸ™ˆ.

⚠️ Default mode is a little extra: the GNU preprocessor's default mode doesn't do a few things the standard requires, and that can quietly change what your program means.

To get 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 must also use -pedantic πŸ”₯.

This manual describes the behavior of the ISO preprocessor 🫢. To cut down on gratuitous differences, where the ISO preprocessor's behavior doesn't conflict with traditional semantics, the traditional preprocessor should behave the same way too πŸ¦‹. The differences that do exist are detailed in the section Traditional Mode πŸ“œ.

For clarity, unless noted otherwise, references to CPP in this manual mean GNU CPP πŸ’–.


✨ OPTIONS ✨

The cpp command expects two file names as arguments: infile and outfile 🧚. The preprocessor reads infile together with any other files it specifies with #include. All the output generated by the combined input files gets written to outfile ✨.

Either infile or outfile may be -. As infile, that means read from standard input. As outfile, it means write to standard output 🌊. If either file is omitted, it's the same as if - had been specified for that file. You can also use the -o outfile option to name the output file πŸŽ€.

Unless otherwise noted, or the option ends in =, all options that take an argument can have that argument right after the option, or with a space between the option and argument. So -Ifoo and -I foo do the exact same thing πŸ’….

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

  • -D name β€” Predefine name as a macro, with definition 1 🌸.
  • -D name=definition β€” The definition gets tokenized and processed as if it showed up during translation phase three in a #define directive. Embedded newline characters truncate the definition βœ‚οΈ.
    • If you're calling the preprocessor from a shell or shell-like program, you might need the shell's quoting syntax to protect characters like spaces that mean something in shell syntax 🐚.
    • Want to define a function-like macro on the command line? Write its argument list with surrounding parentheses before the equals sign (if any). Parentheses mean stuff to most shells, so 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 -D and -U options πŸ”₯.
  • -U name β€” Cancel any previous definition of name, whether it was built in or provided with a -D option 🚫.
  • -include file β€” Process file as if #include "file" appeared as the first line of the primary source file. The difference 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 as 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 are processed before all files specified by -include πŸŽ€.
  • -undef β€” Don't predefine any system-specific or GCC-specific macros. The standard predefined macros stay defined 🌈.
  • -pthread β€” Defines the additional macros required 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, output a rule suitable for make describing the dependencies of the main source file πŸ¦‹. The preprocessor outputs one make rule containing the object file name for that source file, a colon, and the names of all the included files, including those from -include or -imacros command-line options πŸ“œ.
    • Unless you specify it explicitly (with -MT or -MQ), the object file name is the name of the source file with any suffix replaced by the object file suffix, and with any leading directory parts removed. If there are lots 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, such as -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 don't mention header files that are found in system header directories, or header files that get included, directly or indirectly, from such a header 🏰.
    • This means that choosing angle brackets or double quotes in an #include directive doesn't, on its own, 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 no -MF switch is given, 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 together 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 directly 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 in automatic updating of makefiles πŸ”§.

This is what -MP does πŸ› οΈ: it tells CPP to add a phony target for each dependency other than the main file, causing each one to depend 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 such as .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 πŸ›‘οΈ.
    • The default target is automatically quoted, as if it were given with -MQ πŸ’….

-MQ '$(objpfx)foo.o' gives:

$$(objpfx)foo.o: foo.c
  • -fpreprocessed: okay so this one tells the preprocessor the input is already preprocessed 🧚. That means it skips the usual stuff like macro expansion, trigraph conversion, escaped newline splicing, and most directives. It still spots and removes comments, so you can pass a file made with -C to the compiler with zero drama. In this mode the integrated preprocessor is basically just a tokenizer for the front ends. -fpreprocessed is implicit if the input file ends in .i, .ii or .mi, which are the extensions GCC uses for preprocessed files made by -save-temps πŸ’…
  • -fdirectives-only: 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". Macro expansion and trigraph conversion don't happen. Also, -dD gets turned on implicitly.
    • With -fpreprocessed, predefining command line and most builtin macros is disabled. Contextual ones like __LINE__ are still handled normally, which is what lets you compile files that were previously preprocessed with -E -fdirectives-only 🌸
    • With both -E and -fpreprocessed, the -fpreprocessed rules win. That's how you get full preprocessing of files that were previously run through -E -fdirectives-only πŸ‘‘
  • -fdollars-in-identifiers: lets $ show up inside identifiers. Main character energy πŸ’–
  • -fextended-identifiers: accepts universal character names and extended characters in identifiers ✨ This one's on by default for C99 (and later C standard versions) and C++, so you're probably already using it and didn't even know πŸ™ˆ
  • -fno-canonical-system-headers: when preprocessing, stops the system header paths from getting shortened with canonicalization 🧚
  • -fmax-include-depth=depth: sets how deep nested #includes can go. 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 there are tabs 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. Heads up though, it makes the preprocessor and compiler eat more memory. The level parameter lets you pick how precise the tracking is, so you can dial down memory use if you need to:
    • 0 turns this option off.
    • 1 tracks locations in a degraded mode for minimal memory overhead. In this mode, every token that comes from expanding an argument of a function-like macro gets the same location.
    • 2 tracks locations completely. This is the most memory hungry one πŸ”₯

If you give it no argument, the default parameter value is 2. Also, -ftrack-macro-expansion=2 is activated by default, bestie.

  • -fmacro-prefix-map=old=new: when preprocessing files in directory old, __FILE__ and __BASE_FILE__ expand as if the files lived in directory new instead πŸ—ΊοΈ Use . for new to turn an absolute path into a relative one, which can make builds more reproducible and location-independent. This also affects __builtin_FILE() during compilation. See also -ffile-prefix-map.
  • -fexec-charset=charset: sets the execution character set for string and character constants. Default is UTF-8. charset can be any encoding the system's iconv library routine supports πŸ’œ
  • -fwide-exec-charset=charset: sets the wide execution character set for wide string and character constants πŸŽ€ The default is one of UTF-32BE, UTF-32LE, UTF-16BE, or UTF-16LE, whichever matches the width of wchar_t and the big-endian or little-endian byte order used for code generation. Like -fexec-charset, charset can be any iconv encoding, 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 the input file's characters into the source character set GCC uses 🌸 If the locale doesn't specify one, or GCC can't get it from the locale, the default is UTF-8. The locale or this command-line option can override it, but the command-line option wins if there's a conflict. charset can be any iconv encoding.
  • -fworking-directory: turns on linemarkers in the preprocessor output that tell the compiler what the working directory was at preprocessing time πŸ“‚ When it's on, after the initial linemarker the preprocessor emits a second 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 is implicitly enabled when debugging info is on, but you can block it with the negated form -fno-working-directory. If -P is on 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. That one still works, but this one doesn't use shell special characters, so it's way less drama.
  • -A -predicate=answer: cancels an assertion with the predicate predicate and the answer answer 🚫
  • -C: stops discarding comments πŸ’¬ All comments get passed through to the output file, except comments inside processed directives, which get deleted along with the directive. Be prepared for side effects here! With -C, the preprocessor treats comments as tokens in their own right. So comments sitting at the start of what would be a directive line turn that line into an ordinary source line, since the first token isn't a # anymore 😬
  • -CC: stops discarding comments, including during macro expansion 🫢 It's like -C, except comments inside macros also get passed through to the output wherever the macro is expanded. On top of the -C side effects, -CC converts all C++-style comments inside a macro into C-style comments. This stops a later use of that macro from accidentally commenting out the rest of the source line. -CC is generally used to support lint comments 🧹
  • -P: inhibits linemarkers in the preprocessor output 🎈 This might be useful when you're running the preprocessor on something that isn't C code and will get sent to a program that could get confused by linemarkers.
  • -traditional, -traditional-cpp: tries to imitate pre-standard C preprocessors instead of ISO C preprocessors πŸ•°οΈ Note that GCC doesn't otherwise try to emulate a pre-standard C compiler, and these options are only supported with the -E switch or when you invoke CPP explicitly.
  • -trigraphs: supports ISO C trigraphs ✨ These are three-character sequences that all start with ??, and ISO C defines them 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 permit very short file names, like MS-DOS πŸ’Ύ
  • -H: prints the name of each header file used, on top of the other normal stuff πŸ“œ Each name is indented to show how deep it sits in the #include stack. Precompiled header files get printed too, even if they turn out to be invalid. An invalid one shows up with ...x, and a valid one shows up with ...! .
  • -dletters: makes debugging dumps during compilation, as specified by letters πŸ” The flags documented here are the ones relevant to the preprocessor. Other letters are interpreted by the compiler proper, or reserved for future versions of GCC, so they're silently ignored. If you specify letters whose behavior conflicts, the result is undefined, so don't πŸ™…β€β™€οΈ
    • -dM: instead of the normal output, you get a list of #define directives for all the macros defined during preprocessing, predefined ones included πŸ“‹ It's a way of finding out what's predefined in your version of the preprocessor. Assuming you have no file foo.h, this command shows all the predefined macros:
touch foo.h; cpp -dM foo.h
  • -dD: like -dM, except it leaves out 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 it 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. Also, #undef directives are output for macros that were tested but were undefined at the time.
  • -fdebug-cpp: this one is 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 dir to the list of directories searched for header files during preprocessing πŸ“βœ¨

okay bestie, the = and $SYSROOT thing is simple: if dir starts with = or $SYSROOT, that prefix gets swapped out for the sysroot prefix πŸ—ΊοΈ. Check out --sysroot and -isysroot for the full tea β˜•.

Directories given with -iquote only apply to the quote form of the directive, #include "file" πŸ’Œ. Directories given with -I, -isystem, or -idirafter apply to lookup for both #include "file" and #include <file> 🫢.

You can stack as many of these as you want on the command line to search several 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 directories given by -iquote options get searched left-to-right, in the order they show up on the command line πŸ’….
  3. Directories given with -I options get scanned left-to-right πŸ”.
  4. Directories given with -isystem options get scanned left-to-right 🌸.
  5. Standard system directories get scanned πŸ›οΈ.
  6. Directories given with -idirafter options get scanned left-to-right πŸ¦‹.

You can use -I to override a system header file and swap in your own version, since these directories get searched before the standard system header file directories πŸ‘‘. But don't use this option to add directories full of vendor-supplied system header files πŸ™…β€β™€οΈ. Use -isystem for that instead πŸ’–.

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

If a standard system include directory, or a directory given with -isystem, also shows up with -I, the -I option gets ignored πŸ™ˆ. The directory 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 the #include_next directive from getting messed up by accident πŸ”§. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options πŸ’€.


  • -I- β€” Splits the include path βœ‚οΈ. This option is deprecated, so please use -iquote instead for -I directories that come before the -I-, and then remove the -I- option 🚫.

Any directories given with -I options before -I- only get searched for headers requested with #include "file". They don't get searched for #include <file> πŸ’Œ. If extra directories are given with -I options after the -I-, those 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 directory for #include "file". There's no way to override this effect of -I- 😭.

  • -iprefix prefix β€” Sets prefix as the prefix for 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 resulting directory to the include search path πŸ›€οΈ. -iwithprefixbefore puts it in the same spot -I would. -iwithprefix puts it where -idirafter would πŸ¦‹.
  • -isysroot dir β€” This one's like the --sysroot option, but it only applies to header files πŸ“œ. The exception is Darwin targets, where it applies to both header files and libraries 🍎. Check out the --sysroot option for more info πŸ’….
  • -imultilib dir β€” Uses dir as a subdirectory of the directory that holds target-specific C++ headers 🧚.
  • -nostdinc β€” Doesn't search the standard system directories for header files πŸš«πŸ›οΈ. Only the directories explicitly given with -I, -iquote, -isystem, and/or -idirafter options get searched, plus the directory of the current file if it's relevant 🎯.
  • -nostdinc++ β€” Doesn't search the C++-specific standard directories for header files, but still searches the other standard directories 🌸. (This option is 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 turned on by -Wall ✨.
  • -Wtrigraphs β€” Warns if any trigraphs get encountered that could change the meaning of the program ⚠️. Trigraphs inside comments don't get warned about, except for 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 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 the macro gets expanded by an #if directive πŸ™ƒ. This usage isn't portable 🚩. This warning is also turned on 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 a 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 πŸ™Œ.

Note: If a macro is actually used, but only inside skipped conditional blocks, then the preprocessor reports it as unused 😭. To avoid the warning in that case, you might improve the scope of the macro's definition by, for example, moving it into the first skipped block 🧩. Or you could give it a dummy use with something like this:
#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 sometimes happens in older programs with code 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 directories or prefixes to search when looking for include files, or to control dependency output πŸ’….

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, and environment variables 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 πŸ—‚οΈ. You look for header files in these directories. The special character, "PATH_SEPARATOR", depends on the target and gets set at GCC build time πŸ› οΈ. For Microsoft Windows-based targets it's a semicolon ✨, and for almost every other target it's a colon 🌈.

CPATH specifies a list of directories to be searched as if they were given with -I, but after any paths given with -I options on the command line πŸ“. This environment variable gets used no matter which language is being preprocessed πŸ’œ.

The remaining environment variables only apply when preprocessing the particular language they're named for πŸŽ€. Each one specifies a list of directories to be searched as if they were given with -isystem, but after any paths given with -isystem options on the command line 🌸.

In all of these variables, 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 of DEPENDENCIES_OUTPUT can just be a file name. In that case the Make rules get written to that file, and the target name gets guessed from the source file name 🎯. Or the value can have the form file target, in which case the rules get written to file using target as the target name ✍️.

In other words, this environment variable is equivalent to combining the options -MM and -MF, with an optional -MT switch too πŸ’….

  • SUNPRO_DEPENDENCIES β€” This is 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 use in place of the current date and time in the "__DATE__" and "__TIME__" macros πŸ•°οΈ. That way the embedded timestamps stay reproducible πŸ”.

The value of SOURCE_DATE_EPOCH must be a UNIX timestamp, 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 the build process should set it πŸ› οΈ.


πŸ”— SEE ALSO

gpl(7), gfdl(7), fsf-funding(7), gcc(1), and the Info entries for cpp and gcc πŸ“šπŸ¦‹.

Copyright (c) 1987-2020 Free Software Foundation, Inc. πŸ’–

You're allowed to copy, distribute, and/or modify this document under the terms of 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 has 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! 🫢✨ Source: gcc-10, dated 2023-07-07, from CPP(1). You're officially a preprocessor expert now πŸ‘‘πŸ’…πŸ§š

πŸ“¦ where this page comes from