[net.lang.c] __LINE__

ado@elsie.UUCP (Arthur David Olson) (03/03/86)

My April 30, 1985 Draft standard has a "conceptual model" on page 5 that
breaks language processing into these successive phases (among others):

	. . .
	2.  Each instance of a new-line character and an immediately
	    preceding baclslash character is deleted, splicing
	    physical source lines to form logical source lines.
	. . .
	5.  The source is preprocessed. . .

Later, in discussing the preprocessor, the standard reads:

	. . .The line number of the current source line is one greater than
	the number of new-line characters read while processing the source
	file to the current token. . .The predefined macro name __LINE__
	has the value of the line number of the current source line
	(a decimal constant). . .

It's unclear (to me, at least) whether the new-line characters that are
counted in determining __LINE__ are those in the physical source lines
(seen in conceptual phase 2) or those in the logical source lines
(seen in conceptual phase 5, the preprocessing phase).  I'd imagine that
having __LINE__ be a physical source line number would be preferable,
but how can that be accomplished without breaking down barriers between
conceptual phases?
--
	UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie!ado@seismo.ARPA
	DEC, VAX and Elsie are Digital Equipment and Borden trademarks

jsdy@hadron.UUCP (Joseph S. D. Yao) (03/14/86)

In article <6037@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>My April 30, 1985 Draft standard has a "conceptual model" ...
>	2.  Each instance of a new-line character and an immediately
>	    preceding baclslash character is deleted, splicing
>	    physical source lines to form logical source lines.
>	. . .
>	5.  The source is preprocessed. . .
>Later,
>				. . .The predefined macro name __LINE__
>	has the value of the line number of the current source line...
>It's unclear (to me, at least) whether the new-line characters that are
>counted in determining __LINE__ are those in the physical source lines
>(seen in conceptual phase 2) or those in the logical source lines
>(seen in conceptual phase 5, the preprocessing phase).  I'd imagine that
>having __LINE__ be a physical source line number would be preferable,
>but how can that be accomplished without breaking down barriers between
>conceptual phases?

I'd suggest that the info about where in the logical text stream
the various lines start could be saved in a structure passed in
parallel with the "logical" source.  This is not a new idea: think
about how sdb and dbx know about where in the compiled code (surely
less strictly related to the physical source than the logical source)
various physical source code lines start.
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}