Robert Creager <rob...@logicalchaos.org> writes: > On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: >> Robert Creager <rob...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
