[net.lang.c] #line feature in C preprocessor

wartik (02/15/83)

I'm writing some programs using Berkeley Ingres and the EQUEL
preprocessor.  Now this EQUEL was written for version 6, and suffers
from some problems.  For instance, it doesn't insert the #line
directives, so error messages from the C compiler invariably refer to
the wrong line.  I didn't have time to fix EQUEL, so I inserted in each
of my ".q" files the line:

	#line 2 "<filename>.q"

at the beginning of the file.  My trouble is that these files all have
some #include lines following them, and the C preprocessor resets the
file name back to filename.c after an include file is processed!  I
have circumvented the problem once again by placing my #line directive
following all #includes, but what I would like is:

1)	To know if this filename-resetting is a bug or a feature.  By
	the way, has anybody ever produced documentation on the
	preprocessor?  I would greatly appreciate a copy.  Just out of
	curiosity, is the __FILE__ feature described anywhere on vanilla
	Unix other than in /usr/include/assert.h?

2)	If this is a bug, does anybody have the fixes?

3)      Best of all, does anybody have a version of EQUEL that has been
	modified to use the #line directive?  We're running VAXen here,
	so versions that understand their word sizes are preferred, but
	I'll take the source code for a version that works on an 11 if
	it's available.

				Thanks in advance,
					-- Steve Wartik
					decvax!trw-unix!trwspp!wartik
					ucbvax!trw-unix!trwspp!wartik

guy (02/19/83)

I looked at the source to:

1) the V7 version of cpp

2) the 4.1BSD version of cpp

3) the USG UNIX 3.0.1 (System III) version of cpp

and my scan *seems* to indicate that this "feature" may be present in all
versions.  The problem *seems* to be that the only thing that "cpp" does
when it sees '#line nnn file' is to write '# nnn file' to the output.
It also writes '# nnn file', where here nnn is its internal idea of the
current line number and file is its internal idea of the current file,
whenever these change.  Unfortunately, '#line' does NOT change its internal
idea of the current line number or of the current file, it merely causes the
directive to the C compiler to be output.  It looks like it could be made
to reset its internal counters, so I suspect it doesn't for some reason
(i.e., it's probably not a bug).

As of USG UNIX 5.0 (System V), Our Mother who art in Murray Hill documents
both of the major undocumented features of the V7 (John Reiser) C preprocessor.
To wit, the "defined()" operator in #if (permitting you to get the equivalent
of

#ifdef FOO || BAR

by saying

#if defined(FOO) || defined(BAR)

and the __FILE__ and __LINE__ built-in variables.  As such, all you people
who implemented your own preprocessors should go back and put those features
in (especially given that a lot of people have been using them already).

					Guy Harris
					RLG Corporation
					...!decvax!mcnc!rlgvax!guy

guy (02/19/83)

References: sentry1.1425

By the way, re cpp: the V7 "cpy.y" has bugs in the actions for the
!<number>, ~<number>, and -<number> rules: they should read $$ = <op>$2
instead of $$ = <op>$1.  The first two are fixed in the 4.1BSD "cpp", and
the third is fixed in the System III "cpp".  For example, the sequence

#if ((-1)*3) == -3
FOO
#else
BAR
#endif

emits

BAR

on the 4.1BSD "cpp", but

FOO

on the System III "cpp".
					Guy Harris
					RLG Corporation
					...!decvax!mcnc!rlgvax!guy