This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 2.95.1 fixes for backslashes in #line, #include
- To: Paul Eggert <eggert at twinsun dot com>
- Subject: Re: gcc 2.95.1 fixes for backslashes in #line, #include
- From: seebs at plethora dot net
- Date: Mon, 23 Aug 1999 21:24:31 -0500
- cc: gcc-patches at gcc dot gnu dot org, Mike Stump <mrs at wrs dot com>, Zack Weinberg <zack at rabi dot columbia dot edu>
- Reply-To: seebs at plethora dot net
In message <199908240134.SAA03977@shade.twinsun.com>, Paul Eggert writes:
> The last quoted sentence is incorrect, because the ANSI standard says
> only that the behavior of backslashes in file names is defined by
> the implementation.
Actually, it's worse than that; it's flat out undefined. :)
>(Also, this change simplifies the code, so it must be right. :-)
A laudable sentiment. Perhaps it is worth documenting, BTW, that there
are no systems on which you need <foo\bar.h> to process header names?
On NT/'98/etc., <foo/bar.h> will do the same thing.
>+ printf (" -fbs-filenames \\ is ordinary in #include \"...\"\n");
Hmm. And also, if I read this correctly, in #line; is there a good end-user
friendly way to describe all #-directives-which-take-file-names?
>+ if (*fend == '\\' && !bs_filenames) {
>+ char *finc = (char *) fin - 1;
>+ if (*fin == '\"' && pedantic)
>+ pedwarn ("file name contains \"");
Hmm. Two points:
1. You refer to this as "warn only in -pedantic", but I was told that pedwarn
is more like
if (pedantic)
error(foo)
else
warn(foo)
?
2. Hmm. Actually, this is probably not a point; merely pointing out that
" in ""-names isn't allowed by the grammar, whereas " in <>-names is merely
undefined.
>+ if (pedantic)
>+ pedwarn ("concatenated string literals in #include");
I would probably warn anyway - I cannot imagine anyone *meaning* to
concatenate string literals in a #include directive. :)
>[...]This is an extension to the ANSI standard,
>+which prohibits prohibits quotes in @var{file}, and which says that
>+backslashes have implementation-defined behavior. [...]
s/implementation-defined/undefined/
>+containing a newline, a backslash, and a quote. This extends ANSI C,
>+which prohibits quotes in @var{file}, and which says that backslashes
>+have implementation-defined behavior.
&
I will say, this definitely looks like an improvement; it's fairly
readable, and it probably does the least surprising thing for most people.
-s