<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<body text="#000000" bgcolor="#FFFFFF">
<p>I've not looked at the build system configuration *at all*
closely (perhaps a more accurate reading would be "at all"), but
can't you just configure it to not use the offending -W switch
when analyzing/compiling the parser's C code?<br>
<p> - <font color="#000099"><b><font face="Brush Script MT"
size="+3">John D. Bell</font></b></font></p>
On 06/18/2018 04:37 PM, Eric S. Raymond via devel wrote:<br>
<pre wrap="">Hal Murray <a class="moz-txt-link-rfc2396E" href="mailto:email@example.com"><firstname.lastname@example.org></a>:
<a class="moz-txt-link-abbreviated" href="mailto:email@example.com">firstname.lastname@example.org</a> said:
<pre wrap="">It only generates warnings on a few systems. I don't see why not
on the others. ??
<pre wrap="">I looked at the code. Noting mysterious or suspcious there; has to be some
kind of compiler version-skew issue.
Or a glitch in my brain.
I'm seeing it now in modern systems.
Ah, now that's the kind of error pattern I *expect* from Bison parsers.
The underlying problem is that the C in Bison parser skeletons is
really archaic. It dates from times when not even the value of
procedural encapsulation was fully understood - thus all those ugly
globals hanging out in front of God and everybody.
It's not actually in the least difficult to design a skeleton that
gets this right. I did it once. The point is that that warning is nothing
we're doing wrong, it's GCC correctly noticing that the skeleton code kinda
sucks, and we probably *would* have to build a custom skeleton to
fix it. I have seen this movie before.
<meta http-equiv="content-type" content="text/html; charset=utf-8">