Re: gcc 2.95.1 fixes for backslashes in #line, #include

[Paul Eggert <eggert at twinsun dot com>]

   Date: Mon, 23 Aug 1999 19:50:47 -0700
   From: Zack Weinberg <zack@bitmover.com>

   For consistency, we should treat [#include <...>] the same as in
   #include "..."  but I don't remember what the standard says about it.

Good idea.  The standard allows this, except of course that > is also
prohibited within the <...>.  If there's no objection, I'll prepare a
revised patch along those lines.

   From: seebs@plethora.net
   Date: Mon, 23 Aug 1999 21:24:31 -0500

   is [it] worth documenting, BTW, that there
   are no systems on which you need <foo\bar.h> to process header names?

I don't know of any; <foo/bar.h> should work on Microsoft hosts.
If there are any such hosts, then under the above proposal you
can write <foo\\bar.h>; that should suffice.

   >+  printf ("  -fbs-filenames	       \\ is ordinary in #include \"...\"\n");

   ... is there a good end-user friendly way to describe all
   #-directives-which-take-file-names?

I'll try ``\ is ordinary within directives' file names'' in my next
revised patch.

   >+	      if (*fin == '\"' && pedantic)
   >+		pedwarn ("file name contains \"");

   1.  You refer to this as "warn only in -pedantic",

pedwarn means `if (pedantic_errors) error (foo); else warning (foo);',
so you get a warning if -pedantic, and an error if -pedantic-errors.

   " in ""-names isn't allowed by the grammar, whereas " in <>-names is merely
   undefined.

Right.  There needn't be a diagnostic for `#include <">'.

   I cannot imagine anyone *meaning* to concatenate string literals in
   a #include directive.  :)

I can.  E.g. `#include PREFIX FILENAME SUFFIX'.  It could be quite handy.

   s/implementation-defined/undefined/

Thanks for the fix; I'll include it in my revised patch.