drh@duke.cs.duke.edu (D. Richard Hipp) (10/17/90)
When GCC tries to compile the following program: #line 40 "../another_dir/xyzzy.c" #include "incl.h" it gives this error: ../another_dir/xyzzy.c:40: incl.h: No such file or directory 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 other words, if I first type: ln incl.h ../another_dir then everything will work fine. PCC does not exhibit this behavior -- it always looks for the include file in the current directory, regardless of any "#line" directives. Which one is correct? GCC or PCC. The PCC version makes the most sense (to me) but I don't know what ANSI says (if it says anything at all.) Does anyone else know?
henry@zoo.toronto.edu (Henry Spencer) (10/18/90)
In article <656176474@romeo.cs.duke.edu> drh@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... >... PCC does not exhibit this behavior ... >Which one is correct? GCC or PCC. The PCC version makes the most sense >(to me) but I don't know what ANSI says... ANSI says that the #include search procedure is implementation-defined. Sigh. (Bear in mind that ANSI C has no notion of "directory" at all.) 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. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
scs@adam.mit.edu (Steve Summit) (10/20/90)
In article <656176474@romeo.cs.duke.edu> drh@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@zoo.toronto.edu> henry@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@adam.mit.edu