Bison and POSIX requirements

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 15 Dec 2001 12:08:43 +0100

> >> I suppose -v (generation of the textual representation of the
> >> automaton) is, right?
> 
> Paul> Yes.
> 
> Good, thanks!  I suppose there is no specs on the contents/format of
> the contents of this file?

It's only minimally specified.  Here's what POSIX 1003.1-2001 Draft 7
has to say about it (indented) and my comments (not indented).


    The description file shall be a text file containing a description
    of the state machine corresponding to the parser, using an
    unspecified format.

Among other things, "text file" means the file has to be nonempty and
has to end in newline.  I think Bison is OK here.


    Limits for internal tables (see Limits (on page 3274)) shall also
    be reported, in an implementation-defined manner. (Some
    implementations may use dynamic allocation techniques and have no
    specific limit values to report.)...
 
Bison uses dynamic allocation techniques.  And yet it may have limits
anyway, due to the size of 'int' or of 'size_t' or whatever.  However,
I would say that the intent of the standard is to not report these
(large) word-size limits.


    The yacc utility assigns a unique number to each rule. Rules using
    the vertical bar notation are distinct rules. The number assigned
    to the rule appears in the description file....

Hmm, does Bison always assign unique numbers to each rule (and
disjunct) as POSIX requires?  I think so, but I don't know how to
check easily.


    The description file shall contain sufficient information to
    understand the cause of ... [each shift/reduce] conflict....

Bison does this.


    Conflicts resolved by precedence or associativity shall not be
    counted in the shift/reduce and reduce/reduce conflicts reported
    by yacc on either standard error or in the description file....

Bison does this too.


    If any errors are encountered, the run is aborted and yacc exits
    with a non-zero status. Partial code files and header files files
    may be produced. The summary information in the description file
    always shall be produced if the -v flag is present.

Here it seems to me that Bison does not conform to POSIX.  E.g. here's
a quote from the source code:

  /* Stop if there were errors, to avoid trashing previous output
     files.  */
  if (complain_message_count)
    exit (1);

  /* Output the detailed report on the grammar.  */
  print_results ();

which is backwards from what POSIX requires.  A bug!  Should I look
into fixing it?


Here's a quote from the draft rationale, if that helps:

    The format of the y.output file is not given because specification
    of the format was not seen to enhance applications
    portability. The listing is primarily intended to help human users
    understand and debug the parser; use of y.output by a conforming
    application script would be unusual. Furthermore, implementations
    have not produced consistent output and no popular format was
    apparent. The format selected by the implementation should be
    human-readable, in addition to the requirement that it be a text
    file.