The meaning of #line

[J.H.Kim]

Hi, everyone

I saw the preprocessor "#line " in some source codes.
It was like this :
#line 2972 "ifupdown.nw"

Please tell me what is the meaning of that "#line"?

Thanks in advance.

Regards,
J.H.Kim

[Phil Carmody]

"J.H.Kim" <fr******@gmail.comwrites:

Hi, everyone

I saw the preprocessor "#line " in some source codes.
It was like this :
#line 2972 "ifupdown.nw"

Please tell me what is the meaning of that "#line"?

In simple terms, it tells the compiler that the following lines
come from (via some #include) the file 'ifupdown.nw', starting
at line 2972. That way if it needs to print a diagnostic message
to you, it can help point you in the direction of the cause of
the diagnostic message.

Famous places where this extra information can be, on the surface,
completely useless include things like:

"""
struct { int x; } y // no semicolon
#include <stdio.h // compiler will detect something amiss in here
"""
which produces:
"""
In file included from /usr/include/stdio.h:34,
from /tmp/crap.c:2:
/usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h:214: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef'
[...]
"""

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.

[user923005]

On Nov 20, 7:43*pm, "J.H.Kim" <[e-mail]:

Hi, everyone

I saw the preprocessor "#line " in some source codes.
It was like this :
#line 2972 "ifupdown.nw"

Please tell me what is the meaning of that "#line"?

From the C Standard, we have this:

"6.10.4 Line control
Constraints
1 The string literal of a #line directive, if present, shall be a
character string literal.
Semantics
2 The line number of the current source line is one greater than the
number of new-line characters read or introduced in translation phase
1 (5.1.1.2) while processing the source file to the current token.
3 A preprocessing directive of the form
# line digit-sequence new-line
causes the implementation to behave as if the following sequence of
source lines begins with a source line that has a line number as
specified by the digit sequence (interpreted as a decimal integer).
The digit sequence shall not specify zero, nor a number greater than
2147483647.
4 A preprocessing directive of the form
# line digit-sequence "s-char-sequenceopt" new-line
sets the presumed line number similarly and changes the presumed name
of the source file to be the contents of the character string literal.
5 A preprocessing directive of the form
# line pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The
preprocessing tokens after line on the directive are processed just as
in normal text (each identifier currently defined as a macro name is
replaced by its replacement list of preprocessing tokens). The
directive resulting after all replacements shall match one of the two
previous forms and is then processed as appropriate.
158 Language §6.10.4"

[James Kuyper]

J.H.Kim wrote:

Hi, everyone

I saw the preprocessor "#line " in some source codes.
It was like this :
#line 2972 "ifupdown.nw"

Please tell me what is the meaning of that "#line"?

It means that from this point onward in the file, __FILE__ should be
"ifupdown.nw". It also means that __LINE__ should be re-set to 2972, and
start incrementing from there with each newline.

Traditionally, translation phases 1-4 were performed by a separate
pre-processor program, usually called cpp. It is still commonplace for
compilers to provide an option whereby only translation phases 1-4 are
performed; all of the compilers I use most frequently do this when given
a -E command line option. In either case, you're likely to find lots of
#line directives in the output. They are used by the C compiler to
generate error messages that refer to the correct line number in the
correct file name, even when that file was #included.

However, you're also free to insert #line directives of your own, though
I can't imagine any good reason for doing so. I can think of some bad
reasons: imagine the confusion you could create with a #line directive
that sets __FILE__ to "stdio.h".

[Eric Sosman]

James Kuyper wrote:

[...]
However, you're also free to insert #line directives of your own, though
I can't imagine any good reason for doing so. I can think of some bad
reasons: imagine the confusion you could create with a #line directive
that sets __FILE__ to "stdio.h".

One frequent use for #line in "open code" is when the
C source is generated mechanically from some über-source in
another language. The über-to-C translator might insert
#line directives in the generated C to make the compiler's
error messages refer to the über-source (which the programmer
presumably thinks of as "the" source) rather than to the C
source (which the programmer might not even see in the
ordinary course of business).

I believe some yacc versions do this, so the compiler's
complaints are about the .y file rather than about the
generated .c file.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Lorenzo Villari]

"Eric Sosman" <es*****@ieee-dot-org.invalidha scritto nel messaggio
news:gg**********@news.motzarella.org...

I believe some yacc versions do this, so the compiler's
complaints are about the .y file rather than about the
generated .c file.

In fact you do have lots of "#line" in Bison's output for a .y grammar. The
problm with that is if there's an error, the line number is referring to is
always wrong, because the error was in the grammar and not in the generated
c source, so I don't know how useful is that...

[Eric Sosman]

Lorenzo Villari wrote:

"Eric Sosman" <es*****@ieee-dot-org.invalidha scritto nel messaggio
news:gg**********@news.motzarella.org...

> I believe some yacc versions do this, so the compiler's
complaints are about the .y file rather than about the
generated .c file.

In fact you do have lots of "#line" in Bison's output for a .y grammar. The
problm with that is if there's an error, the line number is referring to is
always wrong, because the error was in the grammar and not in the generated
c source, so I don't know how useful is that...

Haven't used bison, but the yacc-ity yaccs I've known have all
allowed the programmer to embed chunks of almost-verbatim C code in
the .y file along with the grammar productions. If the eventual C
compiler spots something wrong with the embedded C code, having the
complaints refer to a location in the .y file is quite helpful.

--
Er*********@sun.com

[Mark L Pappin]

Eric Sosman <es*****@ieee-dot-org.invalidwrites:

James Kuyper wrote:

>[...]
However, you're also free to insert #line directives of your own,
though I can't imagine any good reason for doing so.

One frequent use for #line in "open code" is when the
C source is generated mechanically from some über-source in
another language. The über-to-C translator might insert
#line directives in the generated C to make the compiler's
error messages refer to the über-source (which the programmer
presumably thinks of as "the" source) rather than to the C
source (which the programmer might not even see in the
ordinary course of business).

As in the OP's example (reinserted and rearranged here)

>J.H.Kim wrote:

>>#line 2972 "ifupdown.nw"

where the other language is most likely Noweb, a Literate Programming
tool.

mlp