> I updated my sources and re-ran against Solaris and AIX using lex and
> it doesn't appear to work. The file gets lexed without a hitch now,
> but the .c file it outputs isn't usable.
Well, in any event, taking out the case-insensitivity sped up the
processing by 1.7% (that's not very scientific, mind you).
> On Solaris I get this:
>
> lex -nt dtimep.lex > dtimep.c
> gcc -c -DHAVE_CONFIG_H -I.. -I. -I.. -Wall -O2 dtimep.c
> dtimep.lex:162: warning: return-type defaults to `int'
> dtimep.lex: In function `yylex':
> dtimep.lex:167: `YY_BUFFER_STATE' undeclared (first use in this function)
> dtimep.lex:167: parse error before `lexhandle'
> dtimep.lex:174: `lexhandle' undeclared (first use in this function)
> dtimep.lex:174: warning: implicit declaration of function `yy_scan_string'
> dtimep.lex:174: `lexstr' undeclared (first use in this function)
Um... ick.
This is consistent with lex not honoring the YY_DECL #define, which I
used to masquerade the yylex() functionality as our dparsetime()
function. This yields the return-type warning and the lexstr
undeclaration. This *can* be circumvented with clever tests for flex,
however there would be a slight performance (not enough to notice
during a regular scan or something.)
The more depressing warnings are the YY_BUFFER_STATE and
yy_scan_string() warnings, which means that lex basically has no
mechanism for scanning strings instead of file handles. If you look in
the old zotnet sources, this is why the lexstring.c file exists, and
boy is it ugly. It looks as if it manually calls the internal lexing
routines. Yuck.
There is no straightforward way of overcoming this that I can see of
without making the dateparsing section grossly inelegant, which is
what I was sort of hoping to accomplish.
If noone has *severe* objections, I'd like to drop AT&T lex support in
favor of a more straightforward and maintainable flex version. A
pre-flexed version will come with the distribution, and like Dan said,
it's fairly straightforward to download flex and compile it
yourself. The FSF can probably support more platforms than us.
If endian-ness or unsigned-ness comes to bite us, we could
theoretically have a dtimep/ directory with platform/OS-specific
flexed versions and choose among them, which is undesireable, but less
so than a cludgy lex version.
> On AIX 4.3.3 I get this:
These are the same errors in a different order. ;-(
> Autoconf also didn't set up the Makefile to cause lex to be run at
> all. I had to rm dtimep.c to get it to lex dtimep.lex, which means
> that, as it's set up right now, the flex-lexed version distributed
> will be the one that's used always unless someone removes it by
> hand. At this point that's probablly what we want, anyway, until this
> is fixed.
I'm not sure if you said this in a previous email, but did the flexed
version of dtimep.c in CVS compile on both platforms? If not, we're in
trouble...
Shantonu
