This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C99 status.html query
On Thu, Nov 02, 2000 at 12:18:51AM +0000, Joseph S. Myers wrote:
> On Thu, 2 Nov 2000, Neil Booth wrote:
>
> > So what is not right in the current implementation?
>
> Zack Weinberg said it was broken in July based on a different reading
> (http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00471.html).
That's a different problem. I was talking about 6.10.2 p2-3. The
syntax of #include is supposed to be
# include " <q-char-sequence> "
or # include < <h-char-sequence> >
where <q-char-sequence> :== [^"\n]+
<h-char-sequence> :== [^>\n]+
Last I checked, we were instead doing
# include <string-literal>
# include <h-string-literal>
where <h-string-literal> is <string-literal> with < and > for
delimiters. For the formal definitions of <q-char-sequence> and
<h-char-sequence>, see 6.4.7; for <string-literal> see 6.4.5.
cpplib's string-literal processing doesn't interpret escape sequences.
Therefore, the only way this difference is visible to the user, that I
can think of, is that
#include "\""
#include <\>>
will include files whose names are '\"' and '\>' respectively (shell
syntax). Both should diagnose "junk at end of #include" and look for
a file whose name is '\'. This violates both C89 and C99, but no
one's ever going to notice. It will become a visible problem on
DOS-based hosts if escape sequence processing gets moved into cpplib
(think about #include "sys\types.h"...)
6.10.2 p5 is effectively describing minimum implementation limits on
the length and content of filenames. We're fine there unless someone
tries to port GCC to a filesystem so old it doesn't support eight
characters before the first period. (pdp10-mit-its, anyone?)
zw