|Problem with GIF file scanner (flex) email@example.com (1997-01-25)|
|Re: Problem with GIF file scanner (flex) WStreett@shell.monmouth.com (1997-01-26)|
|Re: Problem with GIF file scanner (flex) firstname.lastname@example.org (1997-01-29)|
|From:||WStreett@shell.monmouth.com (Wilbur Streett)|
|Date:||26 Jan 1997 22:40:50 -0500|
email@example.com (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
>[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
[Flex is supposed to handle null bytes correctly, albeit not quickly. -John]
Return to the
Search the comp.compilers archives again.