Re: Problem with new version of bison's code
Sorry, I omitted the link to the new entry in the Kannel bug-tracker: https://redmine.kannel.org/issues/699#note-5 2018-08-18 11:07 GMT-05:00 Rici Lake : > This is really a problem in kannel, not in bison. Kannel's bison source > file uses a feature which has been deprecated since 2003. Support for this > feature was removed with the bison 3.0 release. > > There's a bug in the kannel bug tracker dating from 2014, which includes a > description of the problem but no good workaround other than using an > obsolete bison version. I updated the bug with a description of the > solution and a patch file which can be applied to the 1.4.5 release to > allow the use of bison v3. (The patch does not affect the use of older > bison versions; I tested it with almost all versions since v2.2.) > > I hope that you will find that useful. > > Rici > > 2018-08-17 3:29 GMT-05:00 : > >> Hello developers of the project "bison"! The task following: There is OS >> Tsentos and sets the Kannel (SMS gateway: https://www.kannel.org/). When >> you install (yum groupinstall "Development tools") "Development tools" >> installed bison version 3.0.4 (bison.x86_64 3.0.4-1.el7 @base). When >> compiling the Kannel, an error occurs: >> >> In file included from wmlscript/wslexer.c:72:0: >> y.tab.h:264:5: error: conflicting types for ‘ws_yy_parse’ >> In file included from wmlscript/wslexer.c:70:0: >> wmlscript/wsint.h:296:5: note: previous declaration of ‘ws_yy_parse’ was >> here >> int ws_yy_parse(void *context); >> ^ >> make: *** [wmlscript/wslexer.o] Error 1 >> >> and all sources >> ( >> http://kannel.6189.n7.nabble.com/Make-ERROR-in-Revision-5141 >> -amp-with-Stable-Release-1-4-4-td31254.html >> https://www.kannel.org/pipermail/users/2014-August/021422.html >> http://kannel.6189.n7.nabble.com/ANNOUNCE-Kannel-1-4-4-stabl >> e-release-available-td30415.html >> ) >> refer to the fact that if you install version 2.5 instead of 3.0.4, then >> the problem is solved. I don't want to use bother this way because the >> installation will have to be repeated many times. And the question >> arises, how can this problem be solved! Thanks in advance >> >> >> >> Sincerely, >> Tursunov Jamshid Asadullaevich >> The Engineer of the Department of Monitoring and Administration >> T: 0 436 227-7698 | M: +998 93 521-7698 | E: ja.tursu...@ngmk.uz >> Navoi Mining & Metallurgical Combinat (NMMC) >> Address: Str. 27 Navoi, Navoi, Uzbekistan, 210100 >> > >
Re: Problem with new version of bison's code
This is really a problem in kannel, not in bison. Kannel's bison source file uses a feature which has been deprecated since 2003. Support for this feature was removed with the bison 3.0 release. There's a bug in the kannel bug tracker dating from 2014, which includes a description of the problem but no good workaround other than using an obsolete bison version. I updated the bug with a description of the solution and a patch file which can be applied to the 1.4.5 release to allow the use of bison v3. (The patch does not affect the use of older bison versions; I tested it with almost all versions since v2.2.) I hope that you will find that useful. Rici 2018-08-17 3:29 GMT-05:00 : > Hello developers of the project "bison"! The task following: There is OS > Tsentos and sets the Kannel (SMS gateway: https://www.kannel.org/). When > you install (yum groupinstall "Development tools") "Development tools" > installed bison version 3.0.4 (bison.x86_64 3.0.4-1.el7 @base). When > compiling the Kannel, an error occurs: > > In file included from wmlscript/wslexer.c:72:0: > y.tab.h:264:5: error: conflicting types for ‘ws_yy_parse’ > In file included from wmlscript/wslexer.c:70:0: > wmlscript/wsint.h:296:5: note: previous declaration of ‘ws_yy_parse’ was > here > int ws_yy_parse(void *context); > ^ > make: *** [wmlscript/wslexer.o] Error 1 > > and all sources > ( > http://kannel.6189.n7.nabble.com/Make-ERROR-in-Revision- > 5141-amp-with-Stable-Release-1-4-4-td31254.html > https://www.kannel.org/pipermail/users/2014-August/021422.html > http://kannel.6189.n7.nabble.com/ANNOUNCE-Kannel-1-4-4- > stable-release-available-td30415.html > ) > refer to the fact that if you install version 2.5 instead of 3.0.4, then > the problem is solved. I don't want to use bother this way because the > installation will have to be repeated many times. And the question > arises, how can this problem be solved! Thanks in advance > > > > Sincerely, > Tursunov Jamshid Asadullaevich > The Engineer of the Department of Monitoring and Administration > T: 0 436 227-7698 | M: +998 93 521-7698 | E: ja.tursu...@ngmk.uz > Navoi Mining & Metallurgical Combinat (NMMC) > Address: Str. 27 Navoi, Navoi, Uzbekistan, 210100 >
RE: Enhancement request: enabling Variant in C parsers
Hi Akim,
> > My main concern is memory management. With Variant the destructors are
> called automatically, but in C parsers I currently have to use %union with
> pointers and explicit "delete". This is not exception-safe and results in ugly
> code littered with "delete" statements. (Using api.value.type is not good
> enough as it makes the types monolithic, so I’d have to select the
> corresponding members manually.)
>
> I don’t understand what you mean here, by monolithic. The parser needs a
> single type to store all the possible types, so, yes, it is monolithic.
Well, I meant that bison looks inside the union and knows its members (I could
have used "opaque", but it would have an unrelated technical meaning in C);
however, I now found the following example in the documentation, so I suppose I
can try creating my own Variant-like type and the parser will still know its
members, so I withdraw my "monolithic" claim. If that works, it would solve my
problem, though having tool support would be nicer.
%code requires
{
struct my_value {
enum{...} kind;
union{...} u;
};
}
%define api.value.type {struct my_value}
%token INT "integer"
%token STR "string"
> Your code is not typical. Traditionally you build an AST in the parser, and
> process the tree elsewhere. That’s why you have so many deletes imho.
> Using the syntax_error exception, you could still raise a syntax error, as if
> it were
> from YYERROR, but from your routine (however, I don’t think type errors
> should be handled by the parser).
I don't mean to be confrontational or anything, but checking types after AST is
built has serious disadvantages:
* the locations must be stored in the AST to report errors
* there is a risk that errors will not be reported correctly, or will be
reported in a wrong order; e.g. the type error could be due to some missing
")", so the parser will happily plough through it and report a syntax error 50
lines later in some innocent fragment of code, and the AST is never completed.
Regards,
Victor.
Re: position.hh compile error C4146 (VisualStudio 2017)
Works for me. (Not that I tried it or anything :-) I don't have Visual
Studio anywhere.)
2018-08-18 10:33 GMT-05:00 Akim Demaille :
>
> > Le 18 août 2018 à 17:10, Rici Lake a écrit :
> >
> >> I don’t remember why I wrote it this way, but today I don’t care much
> >> about INT_MIN here. I think the code has become too complex for what it
> >> meant to do. Also, maybe I should have sticked to int instead of
> trying to
> >> unsigned, but it’s too late to change that :)
> >>
> >>
> > Yes, keeping everything int would have been easier. Or even templating
> the
> > class on a (signed) integer type, so that applications expecting enormous
> > files could deal with them.
>
> That’s the kind of things I’d be happy to deal with later, but I
> first want to push 3.1 outside (smashing all the not too hard bugs
> I can see), and then support move semantics in C++ in 3.2.
>
>
> >> What do you think of my proposal restoring std::max?
> >
> > It's certainly clearer, although of course there are issues with integer
> > overflow on huge inputs (but we don’t care about those, right? -:).
>
> Let’s wait for bug reports about that :)
>
> > Since min is a parameter to add_, you can just make it int instead of
> > unsigned. No point in static_cast(min).
>
> Meh… That way I was sure that min was nonnegative, hence that the
> unsigned I return is « really » nonnegative.
>
> But you’re right, let’s make it simpler.
>
> Good to go?
>
> commit 59f931a50fcd3f3687377507e6e13a6a236d236b
> Author: Akim Demaille
> Date: Sat Aug 18 16:37:47 2018 +0200
>
> C++: fix portability issue with MSVC 2017
>
> Visual Studio issues a C4146 warning on '-static_cast(rhs)'.
> The code is weird, probably to cope with INT_MIN. Let's go back to
> using std::max (whose header is still included in position.hh...) like
> originally, but with the needed casts.
>
> Reported by 長田偉伸, and with help from Rici Lake.
>
> See also
> http://lists.gnu.org/archive/html/bug-bison/2013-02/msg0.html
> and commit 75ae8299840bbd854fa2474d38402bbb933c6511.
>
> * data/location.cc (position::add_): Take min as an int.
> Use std::max.
> While here, get rid of a couple of useless inlines.
>
> diff --git a/THANKS b/THANKS
> index 33f23ed7..c655e3c6 100644
> --- a/THANKS
> +++ b/THANKS
> @@ -173,6 +173,7 @@ Wolfram Wagnerw...@mpi-sb.mpg.de
> Wwp subscr...@free.fr
> xolodho xolo...@gmail.com
> Zack Weinberg z...@codesourcery.com
> +長田偉伸 cbh34...@iret.co.jp
>
> Many people are not named here because we lost track of them. We
> thank them! Please, help us keeping this list up to date.
> diff --git a/data/location.cc b/data/location.cc
> index 3cc949df..07f1ca62 100644
> --- a/data/location.cc
> +++ b/data/location.cc
> @@ -73,12 +73,10 @@ m4_define([b4_position_define],
> unsigned column;
>
>private:
> -/// Compute max(min, lhs+rhs) (provided min <= lhs).
> -static unsigned add_ (unsigned lhs, int rhs, unsigned min)
> +/// Compute max(min, lhs+rhs).
> +static unsigned add_ (unsigned lhs, int rhs, int min)
> {
> - return (0 < rhs || -static_cast(rhs) < lhs
> - ? rhs + lhs
> - : min);
> + return static_cast(std::max(min, static_cast(lhs) +
> rhs));
> }
>};
>
> @@ -134,7 +132,7 @@ m4_define([b4_position_define],
> ** \param pos a reference to the position to redirect
> */
>template
> - inline std::basic_ostream&
> + std::basic_ostream&
>operator<< (std::basic_ostream& ostr, const position& pos)
>{
> if (pos.filename)
> @@ -271,7 +269,7 @@ m4_define([b4_location_define],
> ** Avoid duplicate information.
> */
>template
> - inline std::basic_ostream&
> + std::basic_ostream&
>operator<< (std::basic_ostream& ostr, const location& loc)
>{
> unsigned end_col = 0 < loc.end.column ? loc.end.column - 1 : 0;
>
>
Re: Enhancement request: enabling Variant in C parsers
> Le 18 août 2018 à 17:32, Victor Khomenko a
> écrit :
>
> Hi Akim,
Hey!
>> I don’t understand what you mean here, by monolithic. The parser needs a
>> single type to store all the possible types, so, yes, it is monolithic.
>
> Well, I meant that bison looks inside the union and knows its members (I
> could have used "opaque", but it would have an unrelated technical meaning in
> C); however, I now found the following example in the documentation, so I
> suppose I can try creating my own Variant-like type and the parser will still
> know its members, so I withdraw my "monolithic" claim. If that works, it
> would solve my problem, though having tool support would be nicer.
>
> %code requires
> {
> struct my_value {
> enum{...} kind;
> union{...} u;
> };
> }
> %define api.value.type {struct my_value}
> %token INT "integer"
> %token STR « string"
I’m not sure I understand how this will really help you putting object in the
stack: (non trivial) objects cannot into union. I must be missing your point.
And really, I would like to understand what makes you think it is advantageous
to develop complex storage types for C++ with the C skeletons, rather than
using the C++ skeleton.
>> Your code is not typical. Traditionally you build an AST in the parser, and
>> process the tree elsewhere. That’s why you have so many deletes imho.
>> Using the syntax_error exception, you could still raise a syntax error, as
>> if it were
>> from YYERROR, but from your routine (however, I don’t think type errors
>> should be handled by the parser).
>
> I don’t mean to be confrontational or anything,
So far, so good :)
> but checking types after AST is built has serious disadvantages:
> * the locations must be stored in the AST to report errors
Yes. But even when generating code, it’s kind of useful to be able to report
where it’s coming from. But that depends on the use case, agreed.
> * there is a risk that errors will not be reported correctly, or will be
> reported in a wrong order; e.g. the type error could be due to some missing «
> )", so the parser will happily plough through it and report a syntax error 50
> lines later in some innocent fragment of code, and the AST is never completed.
I do not understand what you mean here. If there’s a parse error and you
invested in error recovery, the parser _must_ build a valid AST. So the error
recovery rules (using the error token) must create a node. Then you have the
choice of using an existing node from your ast, say a dummy int, which can
later produce spurious typing errors, granted. But on this regard, I don’t see
how typing-as-I-parse helps. Also, a better strategy in to introduce a new AST
node to represent precisely that there was an error here, so that the type
checker that keep silent when checking it.
Still, type checking typically requires resolving names, binding from uses to
definitions, i.e., deal with context sensitive matters. And backing context
sensitive issues into a context parser is, IMHO, a sure way for the spaghetti
hell. Keeping the two modules separated is probably slightly more expensive
(in terms in runtime performance), but waay easier to maintain, debug,
upgrade, etc.
Re: position.hh compile error C4146 (VisualStudio 2017)
On Sat, Aug 18, 2018, 10:03 Akim Demaille wrote: > Hi Rici! > > > Le 18 août 2018 à 16:45, Rici Lake a écrit : > > > > Hi, Akim > > > > I'd try > > > > return 0 < rhs || 0 - (static_cast(rhs)) < lhs > > Good idea! > > > Or the redundant but harmless > > > > return 0 < rhs || static_cast(-(static_cast int>(rhs))) < lhs > > > > C4146 is a warning, not an error. It's telling you that if u is > unsigned, -u is still unsigned. The intent is help people avoid doing > things like: > > > > if ( i > -2147483648) ... > > > > which is broken (with 32-bit integers, assuming i is an int) because the > constant is an unsigned int and therefore the comparison will be unsigned, > which will have unexpected results. Or, at least, MS assumes the results > will be unexpected. > > > > As I understand it, your code is precisely trying to avoid the undefined > behaviour possible when using -rhs, if rhs happens to be equal to INT_MIN. > I don’t see any problem with it, but you have to convince Visual Studio > that you know what you're doing. > > I don’t remember why I wrote it this way, but today I don’t care much > about INT_MIN here. I think the code has become too complex for what it > meant to do. Also, maybe I should have sticked to int instead of trying to > unsigned, but it’s too late to change that :) > > > Yes, keeping everything int would have been easier. Or even templating the > class on a (signed) integer type, so that applications expecting enormous > files could deal with them. > > By the way, contrary to the claim in the comment in add_, that function > only works if min is 0 or 1. If min were 2, the return value could be 1. If > the intent is that b4_location_initial_column and b4_location_initial_line > only have 0 or 1 as possible values, it might be clearer to make them > booleans with names like b4_location_column_is_one_based and > b4_location_line_is_one_based. :-) > > Yes, absolutely. But I guess it’s too late too. > > What do you think of my proposal restoring std::max? It's certainly clearer, although of course there are issues with integer overflow on huge inputs (but we don't care about those, right? -:). Since min is a parameter to add_, you can just make it int instead of unsigned. No point in static_cast(min).
Re: position.hh compile error C4146 (VisualStudio 2017)
Hi Rici! > Le 18 août 2018 à 16:45, Rici Lake a écrit : > > Hi, Akim > > I'd try > > return 0 < rhs || 0 - (static_cast(rhs)) < lhs Good idea! > Or the redundant but harmless > > return 0 < rhs || static_cast(-(static_cast int>(rhs))) < lhs > > C4146 is a warning, not an error. It's telling you that if u is unsigned, -u > is still unsigned. The intent is help people avoid doing things like: > > if ( i > -2147483648) ... > > which is broken (with 32-bit integers, assuming i is an int) because the > constant is an unsigned int and therefore the comparison will be unsigned, > which will have unexpected results. Or, at least, MS assumes the results will > be unexpected. > > As I understand it, your code is precisely trying to avoid the undefined > behaviour possible when using -rhs, if rhs happens to be equal to INT_MIN. I > don’t see any problem with it, but you have to convince Visual Studio that > you know what you're doing. I don’t remember why I wrote it this way, but today I don’t care much about INT_MIN here. I think the code has become too complex for what it meant to do. Also, maybe I should have sticked to int instead of trying to unsigned, but it’s too late to change that :) > By the way, contrary to the claim in the comment in add_, that function only > works if min is 0 or 1. If min were 2, the return value could be 1. If the > intent is that b4_location_initial_column and b4_location_initial_line only > have 0 or 1 as possible values, it might be clearer to make them booleans > with names like b4_location_column_is_one_based and > b4_location_line_is_one_based. :-) Yes, absolutely. But I guess it’s too late too. What do you think of my proposal restoring std::max?
Re: position.hh compile error C4146 (VisualStudio 2017)
I tried it and confirmed that it works normally.
Thanks,
2018-08-18 23:45 GMT+09:00 Akim Demaille :
> Please keep bug-bison@gnu.org.
>
>> Le 18 août 2018 à 15:53, 長田偉伸 a écrit :
>>
>> it is still broken.
>>
>>> Can I install this fix?
>>
>>> Would you also consider reporting this bug to MS?
>>
>> Sorry, I can not do anything.
>>
>> Because I can understand English only a little.
>> (I am Japanese)
>
> That’s fine :)
>
> The code was actually stupid. Please try this. Thanks!
>
> commit d32b0c7ee5d39bd33589fc5e62985a68ab78087e
> Author: Akim Demaille
> Date: Sat Aug 18 16:37:47 2018 +0200
>
> C++: fix portability issue with MSVC 2017
>
> Visual Studio dies with parse error on '-static_cast(rhs)'.
> But the code
>
> return (0 < rhs || -static_cast(rhs) < lhs
> ? rhs + lhs
> : min);
>
> was really all wrong, it should have been
>
> return (0 < rhs || static_cast(-rhs) < lhs
> ? rhs + lhs
> : min);
>
> yet let's go back to using std::max (whose header is still included in
> position.hh...) like originally, but with all the needed casts.
>
> Reported by 長田偉伸.
>
> See also
> http://lists.gnu.org/archive/html/bug-bison/2013-02/msg0.html
> and commit 75ae8299840bbd854fa2474d38402bbb933c6511.
>
> * data/location.cc (position::add_): Use std::max.
>
> diff --git a/THANKS b/THANKS
> index 33f23ed7..c655e3c6 100644
> --- a/THANKS
> +++ b/THANKS
> @@ -173,6 +173,7 @@ Wolfram Wagnerw...@mpi-sb.mpg.de
> Wwp subscr...@free.fr
> xolodho xolo...@gmail.com
> Zack Weinberg z...@codesourcery.com
> +長田偉伸 cbh34...@iret.co.jp
>
> Many people are not named here because we lost track of them. We
> thank them! Please, help us keeping this list up to date.
> diff --git a/data/location.cc b/data/location.cc
> index 3cc949df..622ffd61 100644
> --- a/data/location.cc
> +++ b/data/location.cc
> @@ -73,12 +73,11 @@ m4_define([b4_position_define],
> unsigned column;
>
>private:
> -/// Compute max(min, lhs+rhs) (provided min <= lhs).
> +/// Compute max(min, lhs+rhs).
> static unsigned add_ (unsigned lhs, int rhs, unsigned min)
> {
> - return (0 < rhs || -static_cast(rhs) < lhs
> - ? rhs + lhs
> - : min);
> + return static_cast(std::max(static_cast(min),
> +static_cast(lhs) + rhs));
> }
>};
>
>
Re: position.hh compile error C4146 (VisualStudio 2017)
Hi, Akim
I'd try
return 0 < rhs || 0 - (static_cast(rhs)) < lhs
Or the redundant but harmless
return 0 < rhs || static_cast(-(static_cast(rhs))) < lhs
C4146 is a warning, not an error. It's telling you that if u is unsigned,
-u is still unsigned. The intent is help people avoid doing things like:
if ( i > -2147483648) ...
which is broken (with 32-bit integers, assuming i is an int) because the
constant is an unsigned int and therefore the comparison will be unsigned,
which will have unexpected results. Or, at least, MS assumes the results
will be unexpected.
As I understand it, your code is precisely trying to avoid the undefined
behaviour possible when using -rhs, if rhs happens to be equal to INT_MIN.
I don't see any problem with it, but you have to convince Visual Studio
that you know what you're doing.
By the way, contrary to the claim in the comment in add_, that function
only works if min is 0 or 1. If min were 2, the return value could be 1. If
the intent is that b4_location_initial_column and b4_location_initial_line
only have 0 or 1 as possible values, it might be clearer to make them
booleans with names like b4_location_column_is_one_based and
b4_location_line_is_one_based. :-)
Rici
2018-08-18 8:53 GMT-05:00 長田偉伸 :
> > Sorry, it is not clear to me: it still works, or it is still broken?
>
> it is still broken.
>
> > Can I install this fix?
>
> > Would you also consider reporting this bug to MS?
>
> Sorry, I can not do anything.
>
> Because I can understand English only a little.
> (I am Japanese)
>
>
>
> 2018-08-18 22:40 GMT+09:00 Akim Demaille :
> > Please, always keep the list in CC.
> >
> >> Le 18 août 2018 à 15:26, 長田偉伸 a écrit :
> >>
> >> Thank you for your early reply
> >>
> >> I changed the file and then compiled it.
> >> However, the situation has not changed.
> >
> > Sorry, it is not clear to me: it still works, or it is still broken?
> >
> >> - position.hh: 107 - 114
> >>/// Compute max(min, lhs+rhs) (provided min <= lhs).
> >>static unsigned add_ (unsigned lhs, int rhs, unsigned min)
> >>{
> >> //return (0 < rhs || -static_cast(rhs) < lhs
> >> return (0 < rhs || -(static_cast(rhs)) < lhs
> >> ? rhs + lhs
> >> : min);
> >>}
> >> ——
> >
> > Can I install this fix?
> >
> > Would you also consider reporting this bug to MS? Thanks!
>
>
Re: position.hh compile error C4146 (VisualStudio 2017)
Please keep bug-bison@gnu.org.
> Le 18 août 2018 à 15:53, 長田偉伸 a écrit :
>
> it is still broken.
>
>> Can I install this fix?
>
>> Would you also consider reporting this bug to MS?
>
> Sorry, I can not do anything.
>
> Because I can understand English only a little.
> (I am Japanese)
That’s fine :)
The code was actually stupid. Please try this. Thanks!
commit d32b0c7ee5d39bd33589fc5e62985a68ab78087e
Author: Akim Demaille
Date: Sat Aug 18 16:37:47 2018 +0200
C++: fix portability issue with MSVC 2017
Visual Studio dies with parse error on '-static_cast(rhs)'.
But the code
return (0 < rhs || -static_cast(rhs) < lhs
? rhs + lhs
: min);
was really all wrong, it should have been
return (0 < rhs || static_cast(-rhs) < lhs
? rhs + lhs
: min);
yet let's go back to using std::max (whose header is still included in
position.hh...) like originally, but with all the needed casts.
Reported by 長田偉伸.
See also
http://lists.gnu.org/archive/html/bug-bison/2013-02/msg0.html
and commit 75ae8299840bbd854fa2474d38402bbb933c6511.
* data/location.cc (position::add_): Use std::max.
diff --git a/THANKS b/THANKS
index 33f23ed7..c655e3c6 100644
--- a/THANKS
+++ b/THANKS
@@ -173,6 +173,7 @@ Wolfram Wagnerw...@mpi-sb.mpg.de
Wwp subscr...@free.fr
xolodho xolo...@gmail.com
Zack Weinberg z...@codesourcery.com
+長田偉伸 cbh34...@iret.co.jp
Many people are not named here because we lost track of them. We
thank them! Please, help us keeping this list up to date.
diff --git a/data/location.cc b/data/location.cc
index 3cc949df..622ffd61 100644
--- a/data/location.cc
+++ b/data/location.cc
@@ -73,12 +73,11 @@ m4_define([b4_position_define],
unsigned column;
private:
-/// Compute max(min, lhs+rhs) (provided min <= lhs).
+/// Compute max(min, lhs+rhs).
static unsigned add_ (unsigned lhs, int rhs, unsigned min)
{
- return (0 < rhs || -static_cast(rhs) < lhs
- ? rhs + lhs
- : min);
+ return static_cast(std::max(static_cast(min),
+static_cast(lhs) + rhs));
}
};
Re: position.hh compile error C4146 (VisualStudio 2017)
> Sorry, it is not clear to me: it still works, or it is still broken?
it is still broken.
> Can I install this fix?
> Would you also consider reporting this bug to MS?
Sorry, I can not do anything.
Because I can understand English only a little.
(I am Japanese)
2018-08-18 22:40 GMT+09:00 Akim Demaille :
> Please, always keep the list in CC.
>
>> Le 18 août 2018 à 15:26, 長田偉伸 a écrit :
>>
>> Thank you for your early reply
>>
>> I changed the file and then compiled it.
>> However, the situation has not changed.
>
> Sorry, it is not clear to me: it still works, or it is still broken?
>
>> - position.hh: 107 - 114
>>/// Compute max(min, lhs+rhs) (provided min <= lhs).
>>static unsigned add_ (unsigned lhs, int rhs, unsigned min)
>>{
>> //return (0 < rhs || -static_cast(rhs) < lhs
>> return (0 < rhs || -(static_cast(rhs)) < lhs
>> ? rhs + lhs
>> : min);
>>}
>> ——
>
> Can I install this fix?
>
> Would you also consider reporting this bug to MS? Thanks!
Re: YYEOF shouldn't be defined with bison -y
On Sat, 18 Aug 2018 06:39:36 +0200, Akim Demaille wrote: > > Hi! > > I’m coming long after the discussion, sorry. > > > Le 5 déc. 2017 à 02:32, Dimitrios Apostolou a écrit : > > > > On Mon, 04 Dec 2017 21:24:40 +0100, > > Kaz Kylheku wrote: > >> > >> 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 the other hand creates a file that > >>> does > >>> not compile because of undefined symbol YYEOF. > >> > >> What is your error report? > >> > >> Are you saying that you cannot boostrap a build of Bison using Byacc? > > > > My error report has nothing to do with bootstrapping Bison, sorry for not > > being clear. > > > > I am generating a parser as part of a different project, and that project is > > configured with AC_PROG_YACC. As such, it invokes Bison with "-y" option, > > and > > I would expect that Bison tries hard to fail when the parser uses > > non-portable > > features, such as YYEOF. > > > > This is not the case however, and the project was released, and this was > > discovered after longtime that somebody built it with byacc instead of > > Bison. With that version of byacc, the generated parser C code failed to > > build > > with "undefined symbol YYEOF". > > > > I would expect that "bison -y" undefines YYEOF, so that the software that > > uses > > YYEOF fails to build. > > There’s something which is not fully clear here: unless _you_ used YYEOF > somewhere in your code, there’s no reason for the parser not to be > compilable with byacc. Yes, YYEOF was used in the project that I maintained, but I was not the one that introduced it. After years of patches from various people, it was incidentally discovered that the parser fails to compile with byacc, because at some point usage of YYEOF was introduced, and it went undetected, despite having always generated the parser using "bison -y". > So I expect that you did use YYEOF. In which case, the question is rather: > where was it used, to what purpose, and how would you have expected to > write it independently of YYEOF? I'm not sure of the details at the moment, but YYEOF usage got removed eventually. What I did myself to ensure that this does not happen again, I changed the Travis build environment to uninstall bison and install byacc. So now every commit is verified that is yacc-compatible before being merged. Still I believe that "bison -y" ought to catch such errors. Thanks for revisiting this. Dimitris
Re: position.hh compile error C4146 (VisualStudio 2017)
Hi!
> Le 18 août 2018 à 07:36, 長田偉伸 a écrit :
>
> [Description]
>
>I used flex to generate the source code.
>After that, when I compiled using VisualStudio 2017, an error of
> C4146 occurred.
>
>I modified the file containing the error as follows.
>
># (original) position.hh:111
> return (0 < rhs || -static_cast(rhs) < lhs
>
># (edited) position.hh:111
> return (0 < rhs || -1 * static_cast(rhs) < lhs
>
>I compiled it again and confirmed that no error occurred
>
>
> [Environment]
>OS: Windows10
>Visual Studio 2017 (C++)
>
>Version: bison (GNU Bison) 3.0.5
>
>
> Thank you,
Amazing…
According to http://www.externsoft.ch/media/swf/cpp11-iso.html,
we have in the grammar of C++ (with focus on what matters here):
unary_expression:
• postfix_expression
• unary_operator cast_expression
cast_expression
• unary_expression
• '(' type_id ')' cast_expression
unary_operator:
• '+'
• '-'
postfix_expression:
• 'dynamic_cast' '<' type_id '>' '(' expression ')'
• ‘static_cast' '<' type_id '>' '(' expression ')'
So it is my reading that Visual Studio is wrong here.
I don’t like the -1 *, could you please rather check that parens would suffice?
return (0 < rhs || -(static_cast(rhs)) < lhs
Thanks!
Re: documentation: GFDL
Hi!
> Le 9 oct. 2016 à 11:10, dine <2500418...@qq.com> a écrit :
>
> Hi--
> the documentation of GNU Bison includes a copy of the GFDL, however its title
> (i.e. the name of the license) is missing.
Thanks! I installed this in master (for Bison 3.1).
The first part of the patch is just formatting changes (M-q).
commit 2a9d32372ef1a07d3da778e974b3c332d1b81b87
Author: Akim Demaille
Date: Sat Aug 18 14:27:13 2018 +0200
doc: fix the name of the GFDL section
Reported by dine <2500418...@qq.com>.
http://lists.gnu.org/archive/html/bug-bison/2016-10/msg0.html
I mirrored what the Coreutils do.
* doc/bison.texi (Copying This Manual): Rename as...
(GNU Free Documentation License): this, since that the name we
used in the preamble.
diff --git a/doc/bison.texi b/doc/bison.texi
index 28c5e2b3..1d461fe1 100644
--- a/doc/bison.texi
+++ b/doc/bison.texi
@@ -39,18 +39,16 @@ Copyright @copyright{} 1988-1993, 1995, 1998-2015, 2018
Free Software
Foundation, Inc.
@quotation
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License,
-Version 1.3 or any later version published by the Free Software
-Foundation; with no Invariant Sections, with the Front-Cover texts
-being ``A GNU Manual,'' and with the Back-Cover Texts as in
-(a) below. A copy of the license is included in the section entitled
-``GNU Free Documentation License.''
-
-(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
-modify this GNU manual. Buying copies from the FSF
-supports it in developing GNU and promoting software
-freedom.''
+Permission is granted to copy, distribute and/or modify this document under
+the terms of the GNU Free Documentation License, Version 1.3 or any later
+version published by the Free Software Foundation; with no Invariant
+Sections, with the Front-Cover texts being ``A GNU Manual,'' and with the
+Back-Cover Texts as in (a) below. A copy of the license is included in the
+section entitled ``GNU Free Documentation License.''
+
+(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and modify
+this GNU manual. Buying copies from the FSF supports it in developing GNU
+and promoting software freedom.''
@end quotation
@end copying
@@ -110,7 +108,7 @@ Reference sections:
* FAQ:: Frequently Asked Questions
* Table of Symbols::All the keywords of the Bison language are explained.
* Glossary::Basic concepts are explained.
-* Copying This Manual:: License for copying this manual.
+* GNU Free Documentation License:: Copying and sharing this manual
* Bibliography::Publications cited in this manual.
* Index of Terms:: Cross-references to the text.
@@ -390,7 +388,7 @@ Frequently Asked Questions
Copying This Manual
-* Copying This Manual:: License for copying this manual.
+* GNU Free Documentation License:: Copying and sharing this manual
@end detailmenu
@end menu
@@ -13461,8 +13459,9 @@ the parser's start state. A state can become
unreachable during conflict
resolution. @xref{Unreachable States}.
@end table
-@node Copying This Manual
-@appendix Copying This Manual
+@node GNU Free Documentation License
+@appendix GNU Free Documentation License
+
@include fdl.texi
@node Bibliography
position.hh compile error C4146 (VisualStudio 2017)
[Description] I used flex to generate the source code. After that, when I compiled using VisualStudio 2017, an error of C4146 occurred. I modified the file containing the error as follows. # (original) position.hh:111 return (0 < rhs || -static_cast(rhs) < lhs # (edited) position.hh:111 return (0 < rhs || -1 * static_cast(rhs) < lhs I compiled it again and confirmed that no error occurred [Environment] OS: Windows10 Visual Studio 2017 (C++) Version: bison (GNU Bison) 3.0.5 Thank you,
Re: Reported issue is getting old
> Le 5 mars 2016 à 18:50, Balaco Baco a écrit : > > It has been more than a year since an issue has been reported, and no > reply or sign that it is known was shown. The issue is: > > 'make check' does not work for fresh 3.0 and 3.0.4 > http://savannah.gnu.org/support/?108816 > > Please reply to my address too because I'm currently not subscribed to > the list. Hi! Thanks for the report. Please, tell us how it goes with 3.0.5 (or later if there are releases meanwhile). Cheers.
Re: [3.0.4] %printer/%destructor: simple backslashes in paths of #line statements not escaped
> Le 18 août 2018 à 10:06, Akim Demaille a écrit : > > commit adf0425d11fcb60a8171b1c004f1c013789d3a96 > Author: Akim Demaille > Date: Sat Aug 18 09:59:48 2018 +0200 > >escape properly the file names in #line for printer/destructor > >Reported by Jannick. >http://lists.gnu.org/archive/html/bug-bison/2017-05/msg1.html > >"Amusingly" enough, we have the same problem with %defines when the >parser file name has backslashes or quotes: we generate #includes with >an incorrect C string. Well, there is nothing we can do about it, that’s in the syntax of the language: backslashes are not interpreted in #include, so they must not be escaped, and double-quotes, well, can’t be escaped, so must not be used. See https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html#Include-Syntax for instance. This is different from #line, which is explicitly a C string (see https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html#Line-Control).
Re: [3.0.4] %printer/%destructor: simple backslashes in paths of #line statements not escaped
Hi!
> Le 4 mai 2017 à 22:55, Jannick a écrit :
>
> Thanks, J.
This is the shortest (yet precise!) bug report I have ever seen!
Thanks for the report. I am installing this in Bison master. It should be
part of Bison 3.1.0.
Cheers!
commit adf0425d11fcb60a8171b1c004f1c013789d3a96
Author: Akim Demaille
Date: Sat Aug 18 09:59:48 2018 +0200
escape properly the file names in #line for printer/destructor
Reported by Jannick.
http://lists.gnu.org/archive/html/bug-bison/2017-05/msg1.html
"Amusingly" enough, we have the same problem with %defines when the
parser file name has backslashes or quotes: we generate #includes with
an incorrect C string.
* src/output.c (prepare_symbol_definitions): Escape properly the file
names before passing them to M4.
* data/bison.m4, data/lalr1.cc: Don't simply put the file name between
two quotes (that should have been strong enough a smell...), expect
the string to be properly quoted.
* tests/synclines.at: New tests to check this.
diff --git a/NEWS b/NEWS
index 9135184a..760f9399 100644
--- a/NEWS
+++ b/NEWS
@@ -86,6 +86,12 @@ GNU Bison NEWS
were issued with #lines in the middle of C code.
+*** Printer and destructor with broken #line directives
+
+ The #line directives were not properly escaped when emitting the code for
+ %printer/%destructor, which resulted in compiler errors if there are
+ backslashes or double-quotes in the grammar file name.
+
* Noteworthy changes in release 3.0.5 (2018-05-27) [stable]
** Bug fixes
diff --git a/THANKS b/THANKS
index 9d37dc84..9cf3ef22 100644
--- a/THANKS
+++ b/THANKS
@@ -64,6 +64,7 @@ Guido Trentalanciatrent...@aston.ac.uk
H. Merijn Brand h.m.br...@hccnet.nl
Hans Åberghaber...@telia.com
Jan Nieuwenhuizen jann...@gnu.org
+Jannick thirdedit...@gmx.net
Jerry Quinn jlqu...@optonline.net
Jesse Thilo jth...@gnu.org
Jim Kent jk...@arch.sel.sony.com
diff --git a/data/bison.m4 b/data/bison.m4
index 42bb67b8..80e025c9 100644
--- a/data/bison.m4
+++ b/data/bison.m4
@@ -444,7 +444,7 @@ m4_define([b4_symbol_action],
[m4_dquote(b4_symbol([$1], [type]))]),
[(*yylocationp)])dnl
b4_symbol_case_([$1])[]dnl
-b4_syncline([b4_symbol([$1], [$2_line])], ["b4_symbol([$1], [$2_file])"])
+b4_syncline([b4_symbol([$1], [$2_line])], [b4_symbol([$1], [$2_file])])
b4_symbol([$1], [$2])
b4_syncline([@oline@], [@ofile@])
break;
diff --git a/data/lalr1.cc b/data/lalr1.cc
index 053875de..a59ab213 100644
--- a/data/lalr1.cc
+++ b/data/lalr1.cc
@@ -107,7 +107,7 @@ b4_dollar_pushdef([yysym.value],
[m4_dquote(b4_symbol([$1], [type]))]),
[yysym.location])dnl
b4_symbol_case_([$1])
-b4_syncline([b4_symbol([$1], [$2_line])], ["b4_symbol([$1], [$2_file])"])
+b4_syncline([b4_symbol([$1], [$2_line])], [b4_symbol([$1], [$2_file])])
b4_symbol([$1], [$2])
b4_syncline([@oline@], [@ofile@])
break;
diff --git a/src/output.c b/src/output.c
index a28488ed..22c73f1c 100644
--- a/src/output.c
+++ b/src/output.c
@@ -442,7 +442,7 @@ prepare_symbol_definitions (void)
if (p->code)
{
SET_KEY2 (pname, "file");
- MUSCLE_INSERT_STRING (key, p->location.start.file);
+ MUSCLE_INSERT_C_STRING (key, p->location.start.file);
SET_KEY2 (pname, "line");
MUSCLE_INSERT_INT (key, p->location.start.line);
diff --git a/tests/synclines.at b/tests/synclines.at
index b76e47ab..45bac3c0 100644
--- a/tests/synclines.at
+++ b/tests/synclines.at
@@ -329,6 +329,97 @@ exp: '0';
[input.y:2: #error "2"
])
+## -- ##
+## %destructor syncline. ##
+## -- ##
+
+AT_TEST([%destructor syncline],
+[[%destructor {
+#error "2"
+}
+%{
+]AT_YYERROR_DECLARE_EXTERN[
+]AT_YYLEX_DECLARE_EXTERN[
+%}
+%union {
+ int ival;
+}
+%nterm exp
+%%
+exp: '0' { $$ = 0; };
+%%
+]],
+[input.y:2: #error "2"
+])
+
+
+## --- ##
+## %printer syncline. ##
+## --- ##
+
+AT_TEST([%printer syncline],
+[[%printer {
+#error "2"
+}
+%debug
+%code {
+ ]AT_YYERROR_DECLARE_EXTERN[
+ ]AT_YYLEX_DECLARE_EXTERN[
+}
+%union {
+ int ival;
+}
+%nterm exp
+%%
+exp: '0' { $$ = 0; };
+%%
+]],
+[input.y:2: #error "2"
+])
+
+m4_popdef([AT_TEST])
+
+
+
+## -- ##
+## syncline escapes. ##
+## -- ##
+
+# AT_TEST([SKELETON])
+# ---
+m4_pushdef([AT_TEST],
+[AT_SETUP([syncline escapes: $1])
+
+AT_BISON_OPTION_PUSHDEFS([%skeleton "$1"])
+AT_DATA_GRAMMAR([\"\\\"\".y],
+[[%skeleton "$1"
+%code {
+ ]AT_YYERROR_DECLARE[
+ ]AT_YYLEX_DECLARE[
+}
+%destructor {} <>
+%printer {} <>
+%%
+exp: '0'
+%%
+]AT_YYERROR_DEFINE[
+]AT_YYLEX_DEFINE[
+]AT_MAIN_DEFINE[
+]])
+
+AT_FULL_COMPILE([\"\\\"\"])
+AT_BISON_OPTION_POPDEFS
+
