Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!vern
From: vern@hati.cs.cornell.edu (Vern Paxson)
Newsgroups: comp.sources.d
Subject: Re: Flex (latest 2.1 beta) on VMS
Message-ID: <31513@cornell.UUCP>
Date: 29 Aug 89 15:44:08 GMT
References: <13603@bloom-beacon.MIT.EDU> <1664@naucse.UUCP> <482@helps.cactus.org>
Sender: nobody@cornell.UUCP
Reply-To: vern@cs.cornell.edu (Vern Paxson)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 46

In article <482@helps.cactus.org> pcd@helps.UUCP (Paul C. Dingman) writes:
>It appears that flex does not remember the number of characters in the
>input buffer after making a call to yyunput().  A one line change to the
>flex skeleton seems to take care of the problem.
>
>*** src/flex.skel	Sun Jul 30 23:28:22 1989
>--- dist/flex.skel	Mon Aug  7 23:19:28 1989
>***************
>*** 411,417
>  
>  	yy_cp += dest - source;
>  	yy_bp += dest - source;
>- 	yy_n_chars += dest - source;
>  
>  	if ( yy_cp < yy_ch_buf + 2 )
>  	    YY_FATAL_ERROR( "flex scanner push-back overflow" );
>
>--- 411,416 -----
>  
>  	yy_cp += dest - source;
>  	yy_bp += dest - source;
>  
>  	if ( yy_cp < yy_ch_buf + 2 )
>  	    YY_FATAL_ERROR( "flex scanner push-back overflow" );

I believe this is the proper fix ("believe" because I sometimes get
pretty confused with the zillion scanner variables floating around).
A slightly simpler and I think clearer fix is to replace Paul's additional
line with:

	yy_n_chars = YY_BUF_SIZE;

This stresses that yy_n_chars true role (though you wouldn't guess it
from the name) is to point to the *end* of the valid input in the buffer,
which is not necessarily the same as the number of valid characters in
the buffer (because of buffer shifting).  If anyone still has problems
after making this change please let me know; email me a troublesome
input and I'll try to see what's going on.

Thanks, Paul.

		Vern

	Vern Paxson			      vern@cs.cornell.edu
	Computer Science Dept.		      decvax!cornell!cs!vern
	Cornell University