Re: Bison scanner patch to fix POSIX incompatibilities, etc.

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 04 Nov 2002 08:54:02 +0100
> 
> I have not understood why you separated the Yacc and C comments.

I separated the comments because POSIX does.  POSIX gives one
specification for Yacc comments (``Comments shall be enclosed in "/*
... */"'' -- i.e., no backslash-newline processing is done), and a
different one for C comments (e.g., ``An action is one or more C
statements enclosed in curly braces `{' and `}'.'' -- i.e.,
backslash-newline processing should be done).

> why being correct for \, and not for trigraphs?

Because GCC does not process trigraphs by default, and there are good
technical reasons for its departure from the standard here.  Also,
because trigraphs are a real pain to do right.  However, if someone
else wants to contribute trigraph processing as an option, and it's
cleanly implemented, I think it should be added.  (I am lobbying for
having trigraphs removed from the next C standard, so perhaps the
point will become moot.)

> Did you ever see anyone making use of this ``feature''?

Trigraphs?  No.  Backslash-newline?  Yes; it's fairly common (Bison's
grammar has some in its C code), though it's rare within comments and
strings.  I did a quick search and did find one occurrence of
backslash-newline within a C string: an old version of mkid.

While we're on the subject of POSIX conformance, I notice that we're
not handling C digraphs correctly.  I'll throw that in too; might as
well, while I'm at it, since it's easy.

> | -      complain_at (location, _("%s is invalid"), quote (text));
> | +      else
> | +   complain_at (location, _("invalid value: %s"), text);
> 
> Did you mean to remove the `quote' here?

Yes, for two reasons.  First, the value must be of a restricted form
so it doesn't need quoting.  Second, as you eventually noticed,
complain_at itself uses quote slot zero, so it overwrites the slot
zero used by quote (text) and the message is bogus.

> There remains several flavors of error messages.  I prefer `_("invalid
> value: %s")', should we change them all?

Might as well change them now, for values.  I had been trying to avoid
adding new messages since I thought we were close to a 2.0 release and
wanted to avoid burdening the translators.  But now it looks like we
won't have 2.0 out for a bit, and we've added some new messages
anyway, so we might as well do it right.  I'll take a look at it in
the next day or two -- it's fresh in my head so it shouldn't take me
long.  In some cases we can issue a more accurate message
(e.g. "integer out of range: %s").