Question about "#line"

[Steve Summit]

In article <656176474 at romeo.cs.duke.edu> drh at duke.cs.duke.edu (D. Richard Hipp) writes:
>   #line 40 "../another_dir/xyzzy.c"
>   #include "incl.h"
>After some experimentation, I've determined that GCC is trying to include
>the file named "../another_dir/incl.h", not "./incl.h" as I want...

In article <1990Oct18.165143.15463 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>The GCC approach would seem closer to the intent of the standard.  By
>the looks of it, #line changes PCC's error messages but does not affect
>PCC's idea of where the file "really is" for #include search purposes.
>ANSI C just says that #line "changes the presumed name of the source
>file".  In the absence of further qualification, I'd interpret that as
>changing it for all purposes, not just some.

But it can't necessarily change it for ALL purposes.  It occurred
to me recently that a compiler ought to keep two names around:
the one it opened, and the one that #line can alter.  The second
(#line-altered) name is clearly used for error messages, but the
unaltered version is needed if the compiler closes a source file
(after doing an ftell, so that it can fopen it later and fseek to
the same point) when it processes an #include.  This ensures that
#include file nesting depth will not be limited by the number of
open files.  (I am aware that the standard only requires 8
nesting levels for #included files, but it also exhorts us not to
impose fixed translation limits, wherever possible.)

Given the lack of detail in the spec both about what #line does
and what the #include search rules are, I'd say that it would not
be incorrect, and would certainly be less surprising, for a
compiler (if it chooses to search for #includes relative to the
directory of the #includer at all) to do so relative to the
actual file, not as modified by #line.

To my knowldge, #line is most useful for automatically-generated
source files (to arrange that error messages refer to some other
kind of source file, e.g. a yacc grammar, from which the eventual
C source file is being generated).  What is an #include doing
after a #line anyway?  (Or is the problem in fact ocurring in an
automatically-generated source file?)

Actually, given the way the relative-to-the-direcctory-of-the-
#including-file rule is intended to be used, I can come up with
arguments either for the pcc way or the gcc way.

                                            Steve Summit
                                            scs at adam.mit.edu