<html lang="en">
<head>
<title>Line Numbering - The GNU C Preprocessor Internals</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="The GNU C Preprocessor Internals">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="prev" href="Token-Spacing.html#Token-Spacing" title="Token Spacing">
<link rel="next" href="Guard-Macros.html#Guard-Macros" title="Guard Macros">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
pre.display { font-family:inherit }
pre.format { font-family:inherit }
pre.smalldisplay { font-family:inherit; font-size:smaller }
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
span.sc { font-variant:small-caps }
span.roman { font-family:serif; font-weight:normal; }
span.sansserif { font-family:sans-serif; font-weight:normal; }
--></style>
</head>
<body>
<div class="node">
<a name="Line-Numbering"></a>
<p>
Next: <a rel="next" accesskey="n" href="Guard-Macros.html#Guard-Macros">Guard Macros</a>,
Previous: <a rel="previous" accesskey="p" href="Token-Spacing.html#Token-Spacing">Token Spacing</a>,
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
<hr>
</div>
<h2 class="unnumbered">Line numbering</h2>
<p><a name="index-line-numbers-17"></a>
<h3 class="section">Just which line number anyway?</h3>
<p>There are three reasonable requirements a cpplib client might have for
the line number of a token passed to it:
<ul>
<li>The source line it was lexed on.
<li>The line it is output on. This can be different to the line it was
lexed on if, for example, there are intervening escaped newlines or
C-style comments. For example:
<pre class="smallexample"> foo /* <span class="roman">A long
comment</span> */ bar \
baz
⇒
foo bar baz
</pre>
<li>If the token results from a macro expansion, the line of the macro name,
or possibly the line of the closing parenthesis in the case of
function-like macro expansion.
</ul>
<p>The <code>cpp_token</code> structure contains <code>line</code> and <code>col</code>
members. The lexer fills these in with the line and column of the first
character of the token. Consequently, but maybe unexpectedly, a token
from the replacement list of a macro expansion carries the location of
the token within the <code>#define</code> directive, because cpplib expands a
macro by returning pointers to the tokens in its replacement list. The
current implementation of cpplib assigns tokens created from built-in
macros and the ‘<samp><span class="samp">#</span></samp>’ and ‘<samp><span class="samp">##</span></samp>’ operators the location of the most
recently lexed token. This is a because they are allocated from the
lexer's token runs, and because of the way the diagnostic routines infer
the appropriate location to report.
<p>The diagnostic routines in cpplib display the location of the most
recently <em>lexed</em> token, unless they are passed a specific line and
column to report. For diagnostics regarding tokens that arise from
macro expansions, it might also be helpful for the user to see the
original location in the macro definition that the token came from.
Since that is exactly the information each token carries, such an
enhancement could be made relatively easily in future.
<p>The stand-alone preprocessor faces a similar problem when determining
the correct line to output the token on: the position attached to a
token is fairly useless if the token came from a macro expansion. All
tokens on a logical line should be output on its first physical line, so
the token's reported location is also wrong if it is part of a physical
line other than the first.
<p>To solve these issues, cpplib provides a callback that is generated
whenever it lexes a preprocessing token that starts a new logical line
other than a directive. It passes this token (which may be a
<code>CPP_EOF</code> token indicating the end of the translation unit) to the
callback routine, which can then use the line and column of this token
to produce correct output.
<h3 class="section">Representation of line numbers</h3>
<p>As mentioned above, cpplib stores with each token the line number that
it was lexed on. In fact, this number is not the number of the line in
the source file, but instead bears more resemblance to the number of the
line in the translation unit.
<p>The preprocessor maintains a monotonic increasing line count, which is
incremented at every new line character (and also at the end of any
buffer that does not end in a new line). Since a line number of zero is
useful to indicate certain special states and conditions, this variable
starts counting from one.
<p>This variable therefore uniquely enumerates each line in the translation
unit. With some simple infrastructure, it is straight forward to map
from this to the original source file and line number pair, saving space
whenever line number information needs to be saved. The code the
implements this mapping lies in the files <samp><span class="file">line-map.c</span></samp> and
<samp><span class="file">line-map.h</span></samp>.
<p>Command-line macros and assertions are implemented by pushing a buffer
containing the right hand side of an equivalent <code>#define</code> or
<code>#assert</code> directive. Some built-in macros are handled similarly.
Since these are all processed before the first line of the main input
file, it will typically have an assigned line closer to twenty than to
one.
</body></html>