Re: Flex vs. POSIX 1003.2-1992 repeat operator {} precedence

[W. L. Estes]

On Saturday, 27 April 2002,15:55 +0200, Hans-Bernhard Broeker wrote:

> I fully agree to that.  My impression of the whole issue is that this
> essentially a POSIX defect caused by unlucky lack of opposition in the
> discussion.

That would appear to be the case. But we're stuck with the standard
now and so we do need to decide how we're going to deal with that
unfortunate reality.

> I guess the proper way of handling this would be to turn on
> POSIX-sanctioned behaviour only if in -l mode, or if an environment
> variable POSIXLY_CORRECT is set.  Just as some GNU tools do for cases
> where POSIX is at odds with Unix tradition or common practice bad enough
> that most people wouldn't want the tools to strictly follow its rules.

To summarize and so forth from the weekend's postings:

-l will imply the posix-mandated brace-handling because this is how
 AT&T lex did things.

There will be a separate option called "--posix" which will imply all
posix-conforming behaviors not displayed by flex currently. At the
time of writing, the only one is the brace-handling issue.

As far as I can tell,  The option "--posix" will 
 not need to care about flex features which the posix standard does
 not discuss.

The environment variable POSIXLY_CORRECT will imply the option --posix.

> Technically, I think we're safe from POSIX anyway: it only strictly
> applies to the behaviour of /usr/bin/lex, or more generally the
> command "lex".  As long as we don't install a 'flex -l' wrapper
> under that name unless explicitly requested by the person installing
> the package, "flex" isn't "lex", so it can do whatever it wants.
> Being compatible to POSIX' or any other standard's definition of
> "lex" is our choice, not a necessity.

It is our choice, most definitely. We get something by providing a
means of conformance to stupid standards though: flex will be used in
place it wouldn't be used if we didn't provide the possibility of such
conformance.

--Will