[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m4_pattern_forbid
From: |
Matěj Týč |
Subject: |
Re: m4_pattern_forbid |
Date: |
Wed, 18 Mar 2015 01:02:07 +0100 |
On Čt, 2015-03-12 at 16:51 -0600, Eric Blake wrote:
> On 03/12/2015 04:36 PM, Matěj Týč wrote:
> > ...
>
> Would you like to propose a documentation patch to make it clear that
> the flavor of regex in use by this macro is what perl understands?
>
I have done a bit of research on how m4_pattern_forbid works in order to
propose beneficial changes to the documentation and it seems to me that
there is something slightly more going on behind the scenes. I am more a
Python than Perl guy, so I was not able to figure stuff out from the
source code of autom4te though.
What is interesting: I wanted to point out that it should be more
appropriate to write m4_pattern_forbid([\bMACRO]) than ...([^MACRO]),
but I found out that it is not really the true:
cat << EOF | autom4te -l m4sugar
m4_pattern_forbid([^FOO])
m4_divert_push(1)dnl
FOO1
FOO2
hidden FOO3
hiddenFOO4
EOF
yields:
stdin:2: warning: prefer named diversions
FOO1
FOO2
hidden FOO3
-:1: error: possibly undefined macro: FOO1
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
-:2: error: possibly undefined macro: FOO2
-:3: error: possibly undefined macro: FOO3
However, ^FOO should match only FOO2, there is a whitespace in case of
FOO1 and a WORD in case of FOO3, between the FOO and beginning of the
line. At least FOO4 is left alone.
So maybe getting involved \b is not needed under these circumstances?