This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: yacc/bison build errors on current CVS
On 15 Sep 2003 09:51:19 -0700, Ian Lance Taylor <ian@airs.com> said:
>> > Since the material quoted below does not give any details on
>> > the error messages encountered, it is hard to say for sure. But
>> > Flex changed its interface from 2.5.4a -> 2.5.27, and then
>> > changed it again between 2.5.27 and 2.5.31.
> An incompatible change ought to require a jump in version number to
> 3.0. This is a very poor choice by the flex maintainers.
I must confess to being surprised by the magnitude of changes
without a version number change.
>> These changes require source changes in lex input files. The new
>> direction flex is taking is to incorporate new functionality at the
>> expense of POSIX or backward compatibility.
> In my opinion, moving away from default POSIX compatibility would be
> an extremely bad idea.
I can understand the unease. But consider this: POSIX is
already over a decade old; and it standardized practices that were
old at the time the standard was ratified. Some of the proscriptions
laid out in POSIX stood in the way of creating reentrant scanners, or
the ability to have multiple scanners in the same program (with
different defaults, perhaps). The authors of Flex have decided to
pursue functionality, rather then hold to strict adherence of POSIX.
> I don't know if both these claims are true. But if they are, I
> think we need different maintainers for flex.
*Shrug*. You don't have to take my word for it.
The full POSIX references are:
======================================================================
ISO/IEX 9945-2: 1993(3) Information Technology -- POSIX
IEEE Std 1003.2-1992 Part 2: Shell and Utilities
A.2.7.5 lex Actions
Also, there is SUSv3
http://www.opengroup.org/onlinepubs/007904975/utilities/lex.html
======================================================================
POSIX says that the functions yylex, yymore, yyless, input, and unput
are all accessible to user code included in the lex input. As far as
I can tell, POSIX imposes no restriction that the functions are
accessible only to user actions.
It also says that it is unspecified whether the functions or
macros appear in the C code output of lex, or are accessible only
through the -l l operand of the c compiler.
Making the scanner reentrant would conflict with it; the new
flex does not make these functions available outside of user actions.
An important potential problem when using `unput()' is that if you
are using `%pointer' (the default), a call to `unput()' _destroys_
the contents of `yytext', starting with its rightmost character and
devouring one character to the left with each call. If you need the
value of `yytext' preserved after a call to `unput()', you must
either first copy it elsewhere, or build your scanner using `%array'
instead. Also, `yytext' presently does _not_ dynamically grow if a
call to `unput()' results in too much text being pushed back;
instead, a run-time error results.
This unput behaviour is not POSIX or lex compliant. Also, The
`unput()' routine is not re-definable.
manoj
ps: this is my standard blurb for people asking about the new flex
The behaviour of flex has changed in the latest release, yes.
This is part of the gcc migration process; flex has been updated (the
buggy, rickety set of patches required to make it work with gcc was
dumped in favour of a well engineered upstream migration). Please
look at the upstream Changelog for details.
Flex has also grown an extensive test suite, and there is a
test for each of the features reported below. I strongly think that
these changes, which require changes in source, and not a bug, are
causing the vast majority of failures.
As you may see, flex scanners have become reentrant, the c++ versions
are compatible with recent c++ compilers (conform to ANSI C++, gcc
3.2), supports bison variables yylval and yylloc. Some variables have
been renamed. Flex generates C99 defs now; see
YY_TRADITIONAL_FUNC_DEFS yylineno is present in all
scanners. yylineno is per-buffer in reentrant scanners. flex tries
its best to output only the relevant portions of the skeleton when
generating a scanner, thus avoiding as much conditional compilation
as possible
The signature of all functions has changed. flex has new
command line options, and option parsing has changed (now also
supports POSIX conventions optionally). Handles POSIXLY_CORRECT
environment variable. Various i18n translations are included in the
distribution. flex now works with recent bison versions. Flex has
broken backwards compatibility. This is not a bug, but done
deliberately, by design.
--
A cynic is a person searching for an honest man, with a stolen
lantern. Edgar A. Shoaff
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C