Re: C2026 error in VC++ with large number of tokens

[Vince Huffaker]

Hi Akim,

> > Thank you for your reply. See the input file, ApReadBinary.ypp (I have reduced 
> > it greatly from the original).  The HPP file has the bad line at line # 3900 - 
> > the YY_ASSERT is too long.
> >
> > But line 3900 is no long, if you read "line" in the text file sense:
> >     3900         YY_ASSERT (tok == token::YYEOF
> >     3901                    || tok == token::YYerror
> >     3902                    || tok == token::YYUNDEF
> >     3903                    || (token::AF_SMART_POINTER_INT <= tok && tok <= 
> > token::AF_POINT2RD_VECTOR_END)
> >     3904                    || (token::AF_ATTR_MODEL_VIEW <= tok && tok <= 
> > token::AF_ATTR_TEXTURE_MAPPING)
> >     3905                    || (token::AF_TESSELLATION_BEGIN <= tok && tok <= 
> > token::AF_TESS_TRIANGLE_ARRAY)
> > ...
> >     3998                    || (token::CS_PLANE_TO_PLANE3D_V2_END <= tok && tok 
> > <= token::CS_PERPENDICULAR_PLANES3D_REF_V2_END)
> >     3999                    || tok == token::CS_COINCIDENT_POINTS_REF_V4_BEGIN
> >     4000                    || (token::CS_COINCIDENT_POINTS_V4_BEGIN <= tok && tok 
> > <= token::CS_COINCIDENT_POINTS_V4_END)
> >     4001                    || (token::CS_COINCIDENT_POINTS_REF_V4_END <= tok && 
> > tok <= token::CS_CYLINDER3D_V7_END));
> >     4002       }
> So I guess you are telling me that the problem is the "line" in the sense of 
> the C preprocessor?
Correct.

> I guess I should just ignore this assertion when we are under Visual, i.e., 
> emit something like
> > #ifndef MSVC
> >   YY_ASSERT (tok == token::YYEOF
> >              || tok == token::YYerror
> >              || tok == token::YYUNDEF
> >              || (token::AF_SMART_POINTER_INT <= tok && tok <= 
> > token::AF_POINT2RD_VECTOR_END)
> >              || (token::AF_ATTR_MODEL_VIEW <= tok && tok <= 
> > token::AF_ATTR_TEXTURE_MAPPING)
> >              || (token::AF_TESSELLATION_BEGIN <= tok && tok <= 
> > token::AF_TESS_TRIANGLE_ARRAY)
> > ...
> >              || (token::CS_PLANE_TO_PLANE3D_V2_END <= tok && tok <= 
> > token::CS_PERPENDICULAR_PLANES3D_REF_V2_END)
> >              || tok == token::CS_COINCIDENT_POINTS_REF_V4_BEGIN
> >              || (token::CS_COINCIDENT_POINTS_V4_BEGIN <= tok && tok <= 
> > token::CS_COINCIDENT_POINTS_V4_END)
> >              || (token::CS_COINCIDENT_POINTS_REF_V4_END <= tok && tok <= 
> > token::CS_CYLINDER3D_V7_END));
> > #endif
> Could you please add these lines (#ifndef/#endif) and tell me if it does fix 
> your issue?
That macro doesn't seem to exist, but the _MSC_VER does, so this line:

*        #ifndef _MSC_VER**
*
fixes the issue.

> Also, do you really need to specify the numbers for all the tokens?  It is 
> because you gave these numbers that the assertion is long.  If bison had 
> numbered itself, there wouldn't be holes, and the assertions is short.  Why do 
> you provide the token numbers?
We use the Bison parser for reading our native file format.  So, we need 
to make sure that the token values never change, otherwise we would not 
be able to read legacy files.  Therefore, we specifically define the 
values for each token.  Each new version of each object type has its own 
token value, so the numbers keep going up.

But, maybe there's some alternative approach for bison in the future?  
Maybe we could reserve a range of token values... or somehow indicate to 
Bison that our token values are not truly 'custom', but are sequential 
numbers... maybe that would help? Don't know -- just trying ideas..


Is there something I can add to the Bison distribution to automatically 
add that #ifndef line?  Or do I need to wait for a new version?

Thanks!
--Vince--


> Cheers!