bison-patches
[Top][All Lists]
Advanced

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

Proposed interface changes for "parse.error custom"


From: Adrian Vogelsgesang
Subject: Proposed interface changes for "parse.error custom"
Date: Mon, 24 Feb 2020 11:03:29 +0000
User-agent: Microsoft-MacOutlook/10.10.12.200112

Hi,

I have been looking through the “parse.error custom”-interfaces of C and Java 
during the last week.
A few things I would propose that we change while we still can change the 
interfaces:

* We don’t have a getter for the lookahead token. It can only be retrieved 
through yysyntax_error_arguments. I would propose an independent getter for 
just the lookahead token.
* Should yysyntax_error_arguments really be part of the public interface? I see 
that it is used for the builtin error reporting and for testing error reporting 
in the test cases. Still I think that the use case of yysyntax_error_arguments 
is rather narrow and only really fits the error reporting style of bison. I 
would prefer to not expose yysyntax_error_arguments as part of the supported 
interface and instead provide direct access to the lookahead token.
* yacc.c: yysyntax_error_arguments always write at index 0, even for nullptr 
argument. However, we are still checking for nullptr when calling 
yyexpected_tokens. This seems like a contradiction: we are checking for 
nullptr, but then we are crashing if we receive a nullptr nevertheless.
* Java has a different interface for yyexpected_tokens than the other 
languages. It takes an additional yyoffset parameter. We need this, so 
yysyntax_error_arguments can write at offset 1. If we got rid of 
yysyntax_error_arguments, we could have the interface in sync across all 
languages.
* I would prefer if yyexpected_tokens would always return the number of 
expected tokens instead of 0 in case the buffer is too small. I.e., if I pass 
in a pre-allocated array of 5 elements but there are 10 expected tokens, I 
would like still to get a return value of 10. That way, I can always pass in a 
stack-allocated 5-element array as a first try and only do a heap allocation if 
there are more than 5 expected tokens.

Cheers,
Adrian

reply via email to

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