This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: yacc/bison build errors on current CVS

On 15 Sep 2003 09:51:19 -0700, Ian Lance Taylor <> 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  
 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. 

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   <>  <>
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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]