Re: Patches for flex 2.5.25 C compatibility and lint compatibility

[ssikri]

Hi,

I need help...I copied a package from SGI IRIX6.5 machine on redhat 7.2. I did 
some changes in Makefile and my program has compiled successfully. Now the 
problem is when i'm trying to execute it got stuck in yyparse and after 
pressing any key it shows parse error. I changed lex & yacc to flex and Bison. 
After applying flex in debug mode i realized that it gives 'end of buffer or 
NUL'. I don't know what's that. One more thing when i write any word which is 
already specified in grammar then it can read that word from shell but not 
from file and my motive is to generate an output file based on input file. The 
kind of output it shows is as follows, if i write landscape it shows:
landscape
--accepting rule at line 171 ("landscape")
--accepting rule at line 120 ("
")
--(end of buffer or a NUL)
portrait
--accepting rule at line 166 ("portrait")
--accepting rule at line 120 ("
")
--(end of buffer or a NUL)
postscript
--accepting rule at line 160 ("postscript")
--accepting rule at line 120 ("
")
--(end of buffer or a NUL)
as  
--accepting rule at line 948 ("a")
Error 2 in file two_d_rms.wes (line 5), parse error, near "a".fatal error: 
Parser got error, aborting...

I don't know what to do. Please help me.
Shweta
Quoting Bruce Lilly <address@hidden>:

> Attached are two patches for flex 2.5.25.
> 
> compat.patch addresses C type issues related to vaious revisions
> of ANSI C and K&R C.  Both "long long" and int64_t (and uint64_t)
> were introduced with C99, so appropriate typedefs are used in the
> C99 preprocessor branch in flexint.h.  The typedefs were removed
> from the non-64-bit, non-C++ branch since "long long" is an error
> prior to C99.
> 
> lint.patch revises the "/* fall through */" comment to "/*FALLTHROUGH*/"
> which is recognized by lint and lclint (though the latter squawks
> about it not being the lclint proprietary format).
> 
> Both patches have been tested on GNU/Linux (SuSE 8.0/gcc 2.95.3) and
> UWIN 3.1 (MSVC++ 6.0 SP5).
> 
> compat.patch does not address the fact that the [u]intN_t types are
> optional in C99; the typedefs in the C99 branch could be changed
> to the required [u]int_leastN_t C99 types.
>