[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.
Yup.
| 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.
Thanks!
- Re: Bison 1.30f, (continued)
- Re: Bison 1.30f, Paul Eggert, 2001/12/20
- Re: Bison 1.30f, Hans Aberg, 2001/12/21
- Re: Bison 1.30f, Akim Demaille, 2001/12/14
- Re: Bison 1.30f, Paul Eggert, 2001/12/14
- Re: Bison 1.30f, Akim Demaille, 2001/12/15
- Bison and POSIX requirements, Paul Eggert, 2001/12/17
- Re: Bison and POSIX requirements, Hans Aberg, 2001/12/18
- Re: Bison and POSIX requirements,
Akim Demaille <=