On Tue, May 26 2020, Bill Allombert wrote: > On Fri, May 22, 2020 at 03:16:56AM -0700, Manoj Srivastava wrote: >> >> On 12:19 Thursday, 21 May 2020 +0200, Bill Allombert wrote >> > On Wed, May 20, 2020 at 10:03:08PM -0700, Manoj Srivastava wrote: >> > > While it is true that the change was incompatible wwith what we >> > > had befire, the change was made almost four and a half years ago. I >> > > suspect we have gotten used to it now; and changing it back would just >> > > cause issues. >> > >> > Is the new behaviour documented now ? >> > This is needed to use yyinput() properly. >> >> See below. The yyinput usage is demonstrated in an example in >> the info node about generating C++ scanners.
> Well but this is not proper documentation, this is incidental
> documentation at best. Someone writing a C scanner will not read this
> example. Is it documented somewhere that the yyinput API has changed
> ?
Why should a writer of a C scanner care?
,----[ 8 Actions ]
| (Note that if the scanner is compiled using 'C++', then 'input()' is
| instead referred to as yyinput(), in order to avoid a name clash with
| the 'C++' stream by the name of 'input'.)
`----
People writing C++ scanners are likely to see it, and they are
the only ones to care. One could create a github documentation issue
about it if one feels strongly enough.
> Note that the time should be computed between the time the new flex is
> released and the time I report the problem, not between the git commit
> and now.
As far as upstream is concerned when they commited it is when
the feature went out. At thi point, just reverting it is another change
in behaviour. Again, a github issue could be an option if you feel this
strongly about it.
Manoj
--
I don't care where I sit as long as I get fed. -- Calvin Trillin
Manoj Srivastava <sriva...@acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
smime.p7s
Description: S/MIME cryptographic signature
