flex-devel

[Flex-devel] Direct yy_fatal_error instead of YY_FATAL_ERROR macro

[Aaron S. <aa...@se...>]

In the code generated for a reentrant scanner, two functions call
yy_fatal_error directly instead of going through the YY_FATAL_ERROR
macro. I believe this to be an omission. Any objections to changing it?

void libsieve_addrset_lineno (int  line_number , yyscan_t yyscanner)
{
    struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;

        /* lineno is only valid if an input buffer exists. */
        if (! YY_CURRENT_BUFFER )
           yy_fatal_error( "libsieve_addrset_lineno called with no
buffer" , yyscanner);

    yylineno = line_number;
}

And...

void libsieve_addrset_column (int  column_no , yyscan_t yyscanner)
{
    struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;

        /* column is only valid if an input buffer exists. */
        if (! YY_CURRENT_BUFFER )
           yy_fatal_error( "libsieve_addrset_column called with no
buffer" , yyscanner);

    yycolumn = column_no;
}

Cheers,
Aaron

Re: [Flex-devel] Direct yy_fatal_error instead of YY_FATAL_ERROR macro

[Joe K. <kr...@ni...>]

Aaron Stone wrote:
> In the code generated for a reentrant scanner, two functions call
> yy_fatal_error directly instead of going through the YY_FATAL_ERROR
> macro. I believe this to be an omission. Any objections to changing it?
...

Actually, I had changed this in my mega-patch. My modifications are 
fairly extreme, so maybe it would be good if collected general bug-fixes 
  to incorporate into the current code?

Another thing I fixed is the yywrap() macro. The yywrap function has 1 
arg in the reentrant scanner, but zero otherwise. A blank argument is 
valid for a macro, so yywrap(n) is actually valid code for an expression 
using yywrap with either zero or one arguments.

It turns out that at least one broken compiler considers this an error, 
claiming that a 1-argument macro was given zero args. There are also 
non-broken compilers that give warnings. In my modified code, I switched 
to using alternate definitions for yywrap, on the basis that it is 
reasonable to emit warnings in this situation, even though it really is 
valid code.

Joe Krahn

Re: [Flex-devel] Direct yy_fatal_error instead of YY_FATAL_ERROR macro

[Aaron S. <aa...@se...>]

On Tue, 2008-12-02 at 10:36 -0500, Joe Krahn wrote:
> Aaron Stone wrote:
> > In the code generated for a reentrant scanner, two functions call
> > yy_fatal_error directly instead of going through the YY_FATAL_ERROR
> > macro. I believe this to be an omission. Any objections to changing it?
> ...
> 
> Actually, I had changed this in my mega-patch.

Oh cool, well then that makes two people who noticed this and made the
same change, so I'll see about committing it.

>
>  My modifications are 
> fairly extreme, so maybe it would be good if collected general bug-fixes 
>   to incorporate into the current code?

Ah, yes splitting things up is really good practice. Also, I had started
to review your patches but then lost the message list I had open. Lame
excuse, I know, but FYI that reading over your work is on my todo list.

> Another thing I fixed is the yywrap() macro. The yywrap function has 1 
> arg in the reentrant scanner, but zero otherwise. A blank argument is 
> valid for a macro, so yywrap(n) is actually valid code for an expression 
> using yywrap with either zero or one arguments.
> 
> It turns out that at least one broken compiler considers this an error, 
> claiming that a 1-argument macro was given zero args. There are also 
> non-broken compilers that give warnings. In my modified code, I switched 
> to using alternate definitions for yywrap, on the basis that it is 
> reasonable to emit warnings in this situation, even though it really is 
> valid code.

Interesting, I didn't know that!

Aaron

Re: [Flex-devel] Direct yy_fatal_error instead of YY_FATAL_ERROR macro

[Will E. <wl...@us...>]

Yes, we do want to keep bug fixes separate from reorgs and enhancements
and the like.

On Friday,  5 December 2008, 11:23 am -0800, Aaron Stone <aa...@se...> wrote:

> On Tue, 2008-12-02 at 10:36 -0500, Joe Krahn wrote:
> > Aaron Stone wrote:
> > > In the code generated for a reentrant scanner, two functions call
> > > yy_fatal_error directly instead of going through the YY_FATAL_ERROR
> > > macro. I believe this to be an omission. Any objections to changing it?
> > ...
> > 
> > Actually, I had changed this in my mega-patch.
> 
> Oh cool, well then that makes two people who noticed this and made the
> same change, so I'll see about committing it.
> 
> >
> >  My modifications are 
> > fairly extreme, so maybe it would be good if collected general bug-fixes 
> >   to incorporate into the current code?
> 
> Ah, yes splitting things up is really good practice. Also, I had started
> to review your patches but then lost the message list I had open. Lame
> excuse, I know, but FYI that reading over your work is on my todo list.
> 
> > Another thing I fixed is the yywrap() macro. The yywrap function has 1 
> > arg in the reentrant scanner, but zero otherwise. A blank argument is 
> > valid for a macro, so yywrap(n) is actually valid code for an expression 
> > using yywrap with either zero or one arguments.
> > 
> > It turns out that at least one broken compiler considers this an error, 
> > claiming that a 1-argument macro was given zero args. There are also 
> > non-broken compilers that give warnings. In my modified code, I switched 
> > to using alternate definitions for yywrap, on the basis that it is 
> > reasonable to emit warnings in this situation, even though it really is 
> > valid code.
> 
> Interesting, I didn't know that!
> 
> Aaron
> 
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel
> 

-- 
Will Estes (wl...@us...)
Flex Project Maintainer
http://flex.sourceforge.net/