Thread: Re: pure parsers and reentrant scanners

Re: pure parsers and reentrant scanners

From
Tom Lane
Date:
Peter Eisentraut <peter@eisentraut.org> writes:
> I started committing the cube and seg pieces.  There were a couple of 
> complaints from the buildfarm, like
> segscan.c:348:15: error: redefinition of typedef 'yyscan_t' is a C11 
> feature [-Werror,-Wtypedef-redefinition]
> typedef void* yyscan_t;
> ...
> (Also, we should probably figure out a way to get these warnings before 
> things hit the buildfarm.)

Interestingly, while sifaka shows that, its sibling indri doesn't.
Same compiler, same CFLAGS.  I think the relevant difference must
be that sifaka is using a much older Bison version (the Apple-supplied
2.3, versus MacPorts' up-to-the-minute version).  I think that sort of
thing is exactly why we have the buildfarm.  It would not be
reasonable to expect CI to cover that many cases.  Trying to do so
would just make CI slow enough that we'd start looking for a new test
phase to put in front of it.

            regards, tom lane



Re: pure parsers and reentrant scanners

From
Peter Eisentraut
Date:
On 18.12.24 18:43, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> I started committing the cube and seg pieces.  There were a couple of
>> complaints from the buildfarm, like
>> segscan.c:348:15: error: redefinition of typedef 'yyscan_t' is a C11
>> feature [-Werror,-Wtypedef-redefinition]
>> typedef void* yyscan_t;
>> ...
>> (Also, we should probably figure out a way to get these warnings before
>> things hit the buildfarm.)
> 
> Interestingly, while sifaka shows that, its sibling indri doesn't.
> Same compiler, same CFLAGS.  I think the relevant difference must
> be that sifaka is using a much older Bison version (the Apple-supplied
> 2.3, versus MacPorts' up-to-the-minute version).  I think that sort of
> thing is exactly why we have the buildfarm.  It would not be
> reasonable to expect CI to cover that many cases.  Trying to do so
> would just make CI slow enough that we'd start looking for a new test
> phase to put in front of it.

The situation is that most current compilers default to some newer C 
standard version.  And so they won't complain about use of C11 features. 
  But the affected buildfarm members for whatever reason run with 
CC='clang -std=gnu99', and so they correctly reject C11 features.  We 
could do something similar in the Cirrus configuration.  I'll start a 
separate thread about that.