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

[Hans-Bernhard Broeker]

On Sat, 27 Apr 2002, Hans Aberg wrote:

> At 13:37 -0700 2002/04/26, Vern Paxson wrote:
> >> It appears that Vern's intent was
> >> to conform to POSIX, giving priority to POSIX conformance in cases where 
> >> lex
> >> and POSIX diverge.
> >
> >It was more like, (1) I thought lex's precedence rule was really a bad
> >idea, and (2) I was delighted when the POSIX interpretation appeared to
> >align with the more rational precedence rule used by flex.  Had I realized
> >it didn't, I would've fought against it while the POSIX standard was being
> >finalized (as I did for a number of other issues).
>
> Skimming through the posts, I also got the impression that the POSIX
> interpretation of ab{n} as (ab){n} is really bad and invites mistakes.

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.

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.

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.

-- 
Hans-Bernhard Broeker (address@hidden)
Even if all the snow were burnt, ashes would remain.