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

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> I have not understood why you separated the Yacc and C comments.

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

:)  Well, it is not written down, but if they consider C, then yes, I
suppose they mean this weird thing too.

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

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

I do not understand why we would want to have trigraphs.


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

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

Nah: I'm referring to using `\' to split the two characters of */ and
/*.  I mean, the code is ``more correct'' than it was before, but we
might have written code that will just never be used.

The question was: did you ever see a \ splitting tokens in real code
(i.e., cpplib torture tests do not count ;).

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

Really, I see no interest at all in making it that perfect.  I bet big
money that it is not Yacc portable, and I bet people using Bison for
Bison feature are not character-starving, so all this is free
complications that might make things uselessly more complex when we
will "parse" other languages with different lexical structures.

>> Did you mean to remove the `quote' here?

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

OK, I understand.  I agree it is a safe value, but it's easier not to
check where it's from.

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

Paul> Might as well change them now, for values.  I had been trying to
Paul> avoid adding new messages since I thought we were close to a 2.0
Paul> release and wanted to avoid burdening the translators.  

I was thinking the same, but since the string was already in the base,
using it several times does not change much.

Paul> But now it looks like we won't have 2.0 out for a bit, and we've
Paul> added some new messages anyway, so we might as well do it right.

Yep, agreed.

Paul> I'll take a look at it in the next day or two -- it's fresh in
Paul> my head so it shouldn't take me long.  In some cases we can
Paul> issue a more accurate message (e.g. "integer out of range: %s").

Seconded.