On 21. 2. 13., Jung-uk Kim wrote:
> On 21. 2. 12., Mark Johnston wrote:
>> On Thu, Jun 18, 2020 at 06:09:16PM +0000, Jung-uk Kim wrote:
>>> Author: jkim
>>> Date: Thu Jun 18 18:09:16 2020
>>> New Revision: 362333
>>> URL: https://svnweb.freebsd.org/changeset/base/362333
>>>
>>> Log:
>>>   MFV:      r362286
>>>   
>>>   Merge flex 2.6.4.
>>
>> This seems to have introduced a regression: input() now returns 0
>> instead of EOF to indicate that the end of input was reached.  This has
>> been reported in a few places:
>>
>> https://github.com/westes/flex/issues/448
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911415
>>
>> It breaks the scanner used by libdtrace, and as a result dtrace is
>> unable to resolve some probe argument types:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440
>>
>> I have a small patch to libdtrace which works around this.  The upstream
>> commit that introduced the change is fairly old at this point, and
>> upstream seems somewhat unresponsive, so I'm not sure it'll get
>> reverted.  Some other scanners in the tree look like they'd be affected,
>> like crypto/heimdal/lib/asn1/lex.l or
>> sys/contrib/dev/acpica/compiler/aslsupport.l, so I'm wondering if we
>> should revert this particular change for 13.0.  Certainly we should fix
>> the DTrace bug one way or another for 13.0.
> 
> I think it does not make much sense and we should revert the upstream
> change.  Does the attached patch work for you?

Now I believe the author wanted Lex compatibility.  Maybe we should do
the attached patch instead?

Jung-uk Kim
diff --git a/contrib/flex/src/flex.skl b/contrib/flex/src/flex.skl
index 242645f53245..c23b944ea473 100644
--- a/contrib/flex/src/flex.skl
+++ b/contrib/flex/src/flex.skl
@@ -1863,7 +1863,11 @@ m4_ifdef( [[M4_YY_USE_LINENO]],
 				case EOB_ACT_END_OF_FILE:
 					{
 					if ( yywrap( M4_YY_CALL_ONLY_ARG ) )
+#ifdef YY_FLEX_LEX_COMPAT
 						return 0;
+#else
+						return EOF;
+#endif
 
 					if ( ! YY_G(yy_did_buffer_switch_on_eof) )
 						YY_NEW_FILE;

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to