Re: Problem with GIF file scanner (flex)

kxn@dcs.ed.ac.uk (Kristian Nilssen) wrote:


>The following flex code is supposed to scan a GIF file. A GIF file
>begins with a Header and then a Logical Screen Descriptor. For some
>unknown reason, flex will not enter the Logical_Screen_Descriptor
>state.


<snip>


>[Hmmn. People don't often use flex for scanning non-text data, so you may
>have tripped over a bug. -John]


I think it's more of a slight design flaw, or design intention issue.
As you said, it was originally intentioned for regular text.


Kristian, check out the definition of the YY_INPUT macro. It may be
that FLEX is assuming that a NULL, (0x0), is the end of file marker.
That in turn is causing may be calling yy_wrap() function to be called
because of a false end of file, and that is probably reseting your
start state. You can trace all of this in source, so it's not
impossible to figure out.


FLEX is very flexible.. so you can simply define your own YY_INPUT
macro and get aorund the null character issue there, but it may be
other places where NULL trailing bytes as field ends would conflict
with NULL bytes in the data. You can redefine all of the input macros
and do whatever you'd like.. I suggest that you check through the
documentation, I seem to recall some discussion of handing NULL's
documented somewhere.


Wilbur
[Flex is supposed to handle null bytes correctly, albeit not quickly. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.