Robert Creager <robert@logicalchaos.org> writes:
> On Sep 7, 2009, at 1:18 PM, Tom Lane wrote:
>> Robert Creager <robert@logicalchaos.org> writes:
>>> extern yy_size_t yyleng;
>>
>> Bizarre --- my copy of flex 2.5.35 definitely puts out "int", and
>> so does everybody else's. Did Apple take it on their own head to
>> change this?
> Apparently so - the /opt version is from macports. It works.
[ Well, I knew I was going to be buying a copy of Snow Leopard sometime
soon. One trip to the Apple store later ... ]
Yeah, I've confirmed this. It appears that Apple has absorbed this
as-yet-unreleased upstream patch into their "2.5.35" version:
http://flex.cvs.sourceforge.net/viewvc/flex/flex/flex.skl?r1=2.212&r2=2.213
This is probably not the brightest thing the flex developers have ever
done, as there is now absolutely no way to predict the type of yyleng
externally to the generated scan.c file. They might as well not export
it at all.
However, I think we can work around it. AFAICS, the only reason ecpg
has an extern for yyleng is because preproc.y's make_name() uses it,
and there doesn't seem to be any compelling reason why that function
shouldn't just do "mm_strdup(yytext)" instead. I don't see any other
places where we are referring to yyleng outside of a scanner file.
(Alternatively, make_name() could be moved into pgc.l, but I doubt
it's worth the work to avoid one extra strlen calculation.)
Presumably, versions of flex containing this change will start to show
up at other places besides Apple sometime soon. So I'm thinking we
need to back-patch the fix to whatever branches we think are likely
to get compiled from CVS on newer platforms. Any feelings about that?
Should I just hit everything back to 7.4 to be safe?
regards, tom lane