[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bison and POSIX requirements

From: Akim Demaille
Subject: Re: Bison and POSIX requirements
Date: 22 Dec 2001 16:37:17 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

| > 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).

Thanks for all these details!  And more generally, thanks for the help
you give us on Bison (and others :).

|     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.

There are many places where shorts are used instead of ints, so we
certainly hit some limits very early.  OTOH, I have never seen a
report for `too low a limit'.

|     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.

It does, and it does report them.

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

More or less.  This is *much* room for improvement, but it requires a
lot of internal surgery.

|     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.

It does the two :)

|     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?

Sure, thanks!

| 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]