Re: m4_pattern_forbid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?


_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf





[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux