Re: build: bison compat: colour mess

On 2024-04-26 12:54, Steffen Nurpmeso wrote: > Hello. > > I come over via https://github.com/onetrueawk/awk/issues/228. > For years the nawk build causes terminal mess in the unshare(1)d > fakeroot(1) package build environment of the Linux distro i use > (CRUX; sh(1) based). It looks like that:

Re: Enhancement Request

On 2022-09-06 13:54, Arthur Schwarz wrote: > Hi Akim; > > After a while I decided, why not. I might just as well answer you. Thanks for > your response. This will be a summary and not a point-to-point answer. It is > clear that Bison does not want to, and will  not, proceed forwards, and so, >

Re: Bison submit patches

On 2022-08-22 03:19, Andrei Malashkin wrote: > Dear Sir or Madam, > > please consider adding these patches to the next bison release These patches are targeting files that are not found in GNU Bison, so the changes cannot be merged into Bison. GNU Bison doesn't have a patches/ directory; it

Re: Enhancement Request

On 2022-06-17 10:58, slipbits wrote: > Given that Bison has the ability to (and does) generate a parser for > itself, is there any possibility of removing all %code tags in future > releases. This is not clear; remove what from where? For what purpose? How does Bison being partially self-hosted

Re: Section 3.1.2 has what appears to be a bug

On 2022-06-17 10:26, slipbits wrote: > 3.1.2 Prologue Alternatives, pg. 50 >“and the new YYLTYPE definition before the Bison-generated YYSTYPE >and YYLTYPE definitions in both the parser implementation file and >the parser header file”. > >This position causes, in this case,

Re: 3.3 Grammar Rules Issues

On 2022-06-11 13:38, slipbits wrote: > You nowhere define the syntax and grammar of Bison in one place. Ah, but that is only the case if we are talking strictly about documentation. There is a grammar of Bison given in Bison in the source tree:

Re: Non-grammatical statements

On 2022-06-08 13:10, slipbits wrote: > 3.7.13 Bison Declaration Summary > > "Directive: *%token-table* > >This feature is obsolescent, avoid it in new projects." > > "obsolescent" should be "obsolete" This is incorrect. "Obsolescent" is a word, and it's used correctly here; it is the right

Re: Flex size_t sizes

On 2021-11-13 13:18, Hans Åberg wrote: This works as long as nobody tries to compile the .ll file with an incompatible Flex version even in the case the header is shipped. Your build system has to handle that situation. If the downstream user builds your program in such a way that the .ll file

Re: Flex size_t sizes

[Replying to HTML with HTML] On 2021-11-13 02:17, Hans Åberg wrote: > On 12 Nov 2021, at 23:41, Kaz Kylheku wrote: > >> I see that, for instance on a Ubuntu 18 system here, there is a >> /usr/bin/FlexLexer.h file. >> >> This is an incredibly, incredibly bad

Re: Flex size_t sizes

On 2021-10-14 06:23, Hans Åberg wrote: Hi Akim, Saw you have edited Flex, so I take it up here, even though not strictly a Bison topic: The Apple flex version has been edited to admit size_t sizes, 64-bit on the platform, and perhaps it might be good idea for regular flex, which uses int, only

Re: Different conflicts between byacc and bison

On 2021-11-04 01:57, Domingo Alvarez Duarte wrote: Also tested with the latest byacc from https://invisible-island.net/byacc/: ./yacc -V ./yacc - 2.0 20210808 byacc-20210808/yacc gram.y byacc-20210808/yacc: 21 shift/reduce conflicts, 3 reduce/reduce conflicts. Now, I've not looked at

Re: quirks in parse-gram.y

On 2021-04-21 22:06, Akim Demaille wrote: Le 20 avr. 2021 à 04:18, 叶雨飞 a écrit : 2. The rules grammar indicate an ending “;” is actually optional. In fact, the parse-gram.y missed two “;” in separate places. However the doc is pretty clear an “;” is expected. Not sure which is intended .

Re: api.header.include and backward-compatible .y files

On 2020-09-19 02:07, Akim Demaille wrote: no. *You* seem to believe Bison should not generate the signature of yyparse in the header. But that's Kaz, not the typical use case. And instead of just accepting that, you decided to fight it. To clarify, I believe that since yyparse is an

Re: api.header.include and backward-compatible .y files

On 2020-09-08 12:18, Adam Novak wrote: It sounds like Bison is designed around the GNU project way of doing software development, where there exist "maintainers" who are different from end users, and who have an opportunity to prepare "releases" which either contain more files than are checked

Re: Make perl & examples optional

On 2020-09-07 22:46, Akim Demaille wrote: Hi Kaz, hi Thomas, Le 7 sept. 2020 à 08:57, Kaz Kylheku a écrit : On 2020-09-06 09:13, Akim Demaille wrote: Hi Thomas, Le 6 sept. 2020 à 16:41, Thomas Deutschmann a écrit : Hi, in Gentoo Linux we are carrying the following patch for quite some

Re: api.header.include and backward-compatible .y files

On 2020-09-06 00:46, Akim Demaille wrote: Kaz, Le 5 sept. 2020 à 17:58, Kaz Kylheku a écrit : On 2020-08-30 05:21, Akim Demaille wrote: Hi Adam, Le 22 août 2020 à 02:33, Adam Novak a écrit : Hello, I'm maintaining a .y file at https://github.com/vgteam/raptor/blob/master/src

Re: Make perl & examples optional

On 2020-09-06 09:13, Akim Demaille wrote: Hi Thomas, Le 6 sept. 2020 à 16:41, Thomas Deutschmann a écrit : Hi, in Gentoo Linux we are carrying the following patch for quite some time to make perl dependency which is required for examples optional. Any chance to get this applied

Re: Help with new test case.

On 2020-09-06 00:52, Akim Demaille wrote: Kaz, Le 5 sept. 2020 à 21:41, Kaz Kylheku a écrit : On 2020-09-05 00:59, Kaz Kylheku wrote: Hi, I'm trying to add a test case in the form of a new entry in examples/c. Examples are show cases, they are no tests. They are there to serve

Re: Help with new test case.

On 2020-09-05 00:59, Kaz Kylheku wrote: Hi, I'm trying to add a test case in the form of a new entry in examples/c. I moved all the build rules into local.mk, and got it to work. 'examples/c/buildscenario/buildscenario.c', needed by 'examples/c/buildscenario

Re: api.header.include and backward-compatible .y files

On 2020-08-30 05:21, Akim Demaille wrote: Hi Adam, Le 22 août 2020 à 02:33, Adam Novak a écrit : Hello, I'm maintaining a .y file at https://github.com/vgteam/raptor/blob/master/src/turtle_parser.y that needs to be backward-compatible with the Bison available in Ubuntu 18.04 (3.0.4), but

Re: api.header.include and backward-compatible .y files

On 2020-08-30 05:42, Akim Demaille wrote: Let's face it: the POSIX spec for Yacc contains a lot of silly things. For instance using #define for tokens is silly. enums are the obvious right choice. I happen to have an #ifdef test for one of these tokens, which is a proxy for "y.tab.h has been

Help with new test case.

Hi, I'm trying to add a test case in the form of a new entry in examples/c. The test case is a "build scenario": a small version of a program that is built a certain way, with its own Makefile. I prepared everything stand-alone; I'm just integrating it into the tree. I need the "local.mk" to

Re: api.header.include and backward-compatible .y files

On 2020-08-21 17:33, Adam Novak wrote: Hello, I'm maintaining a .y file at https://github.com/vgteam/raptor/blob/master/src/turtle_parser.y that needs to be backward-compatible with the Bison available in Ubuntu 18.04 (3.0.4), but also work on the latest Bison that our project's Mac users get

Re: api.header.include and backward-compatible .y files

On 2020-08-21 17:33, Adam Novak wrote: Hello, I'm maintaining a .y file at https://github.com/vgteam/raptor/blob/master/src/turtle_parser.y that needs to be backward-compatible with the Bison available in Ubuntu 18.04 (3.0.4), but also work on the latest Bison that our project's Mac users get

Unhelpful noisy diagnostics from newer Bison.

Hi, Please clean up the following: $ make YACC parser.y -> y.tab.c parser.y:106.1-12: warning: POSIX Yacc does not support %pure-parser [-Wyacc] 106 | %pure-parser | ^~~~ parser.y:106.1-12: warning: deprecated directive, use ‘%define api.pure’ [-Wdeprecated] 106 |

Re: [PATCH 0/3] yacc: compute the best type for the state number

On 2019-10-01 22:27, Akim Demaille wrote: Apparently like Kaz, I like to name my types *_t, so I'd be happy with yy_state_t (scalars) and yy_state_least_t/yy_small_state_t (arrays) The claiming of _t by POSIX is largely bunk. Here is one counterargument: 1. Every finite string has the empty

Re: [PATCH 0/3] yacc: compute the best type for the state number

On 2019-10-01 06:53, Hans Åberg wrote: One should note that the unsigned types are required to be 2’s complement C/C++, unlike the signed ones, cf. That is untrue by definition, since two's complement is strictly a mechanism for representing negative values, which the unsigned types do not do.

Re: [PATCH 0/3] yacc: compute the best type for the state number

On 2019-10-01 01:35, Paul Eggert wrote: On 9/29/19 11:34 AM, Akim Demaille wrote: As a matter of fact, we used two types: - most arrays (such as state stack, and its correspondance in the LAC infrastructure) are using int16_t. A few "temporary" variables also have this type. - yystate,

Issue in bison error format.

Hi all, Errors from Bison look like this: parser.y:876.63: invalid character: `}' This format differs in a small detail from the usual GCC one and so, for instance, the Vim editor doesn't understand it; it won't jump to the error location. If we change it to: parser.y:876:63: invalid

Re: Calling yyerror with non-literal parameter triggers warning

On 2019-08-19 13:05, August Karlstrom wrote: When I use the default C compiler cc on macOS to compile a parser generated by GNU Bison I get the following warning: y.tab.c:3974:18: warning: format string is not a string literal (potentially insecure) [-Wformat-security] yyerror

Re: O_BINARY no longer defined

On 2019-08-09 13:33, Paul Eggert wrote: On 8/9/19 7:47 AM, Akim Demaille wrote: I don't understand how come builds that used to work stopped passing, and now pass again. I call them "Heisenbuilds". They're even more annoying than molasses builds. It's very easy to cause heisenbuilds; just

Re: Please, support easy AST generation

On 2018-12-08 16:45, Askar Safin wrote: Hi. Often the only thing I want to do in Bison is just generate AST and nothing else. Unfortunately, in this case code becomes very repetitive. I think the generation of *parse trees* can be automated. AST's omit information from (abstract away from)

Re: Any help needed?

On 2018-05-08 04:03, Vlad Vladov wrote: Good day, I am interested in contributing to the project. Is there anything I can help with? Hi Vlad, Bison/Yacc has an annoying limitation. When you call yyparse, it parses the entire grammar down to the start symbol. Sometimes you just want to

Re: Bison Skeleton: irksome GPL license.

On 2018-04-18 01:36, Hans Åberg wrote: On 18 Apr 2018, at 02:16, Kaz Kylheku <k...@kylheku.com> wrote: (Side note: this is a different behavior from GNU Flex, which passes through the comment even if is outside of the %{ ... %} block). No, it doesn't, not in my code. In some circums

Re: Bison Skeleton: irksome GPL license.

On 2018-04-16 13:27, Hans Åberg wrote: On 16 Apr 2018, at 22:01, Kaz Kylheku <k...@kylheku.com> wrote: When Bison turns a .y file into a y.tab.c, it removes any license header from the .y file, and asserts its own license over the file (which comes from the parser skeleton). *Rep

Bison Skeleton: irksome GPL license.

When Bison turns a .y file into a y.tab.c, it removes any license header from the .y file, and asserts its own license over the file (which comes from the parser skeleton). It says that the entire file is free software redistributed under terms of the GPL (with a dubious exception that it may be

Re: syntax_error constructor is declared inline

On 2018-03-13 13:31, Hans Åberg wrote: On 12 Mar 2018, at 20:08, Vishal V wrote: Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' when generating a C++ scanner, which results in undefined references when the exception is thrown from a

Re: YYEOF shouldn't be defined with bison -y

On 04.12.2017 17:32, Dimitrios Apostolou wrote: Alright, so maybe it's not a bug. But if that's the case, what's the recommended way to ensure that the parser is portable to most yacc flavours? Install the set which represents "most flavors" in your opinion, make your build system flexible

Re: YYEOF shouldn't be defined with bison -y

On 03.12.2017 18:34, Dimitrios Apostolou wrote: Hello list, I am configuring the build using AC_PROG_YACC, which invokes bison with "-y" option. But bison-generated parser compiled successfully, and YYEOF extension in the parser remained undetected. Generating the parser with "byacc" on

Re: Bison C++ mid-rule value lost with variants

On 29.06.2017 06:55, Piotr Marcińczyk wrote: I supposedly found a bug in lalr1.cc skeleton with variant semantic type. When using mid-rule action { $$ = value; } to return a value that will be used in further semantic actions, it appears that the value on stack becomes zero. Tested with Bison

Re: bison 3.0.4 %destructor is c++ mode seems to be called even in the normal parse

On 18.08.2016 12:05, Min Wang wrote: HI @kaz. thanks. I will check the %union later I'like to use the smart pointers ( std::unique_ptr) , but somehow I got some compiler errors. here are some details: e.g: using PROG_PTR = std::unique_ptr; "using" is now a full-blown alternative for

Re: yyparse being prototyped in y.tab.h causes problems.

On 19.08.2015 11:26, Akim Demaille wrote: Le 19 août 2015 à 15:38, Kaz Kylheku k...@kylheku.com a écrit : On 18.08.2015 23:24, Akim Demaille wrote: As you reported, the standard does not even report YYSTYPE, which is clearly needed. Reported to Austin group yesterday; http

Re: yyparse being prototyped in y.tab.h causes problems.

On 18.08.2015 02:06, Akim Demaille wrote: Le 14 août 2015 à 18:14, Kaz Kylheku k...@kylheku.com a écrit : If we translate parser.y with bison --yacc -d to generate a y.tab.h and y.tab.c, the y.tab.h contains: int yyparse (private_context *ctx); I think that adding %code requires

Re: yyparse being prototyped in y.tab.h causes problems.

On 18.08.2015 06:35, I blundered: Hi Akim, The example I gave is (to my best knowledge and effort) POSIX-conforming Yacc code. Hi Akim, and everyone, Sorry for the above nonsense; of course it obviously is not due to the %pure-parser %parse-param{private_context *ctx} which is

yyparse being prototyped in y.tab.h causes problems.

Simple two-file test case: /* parser.y - */ %{ #include stdio.h typedef struct { int dummy; } private_context; %} %pure-parser %parse-param{private_context *ctx} %union { char *str; } %tokenstr TOK %typestr start %% start : TOK { $$ = $1; } %% int