[Top][All Lists]

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

Re: M4 syntax $11 vs. ${11}

From: Ralf Wildenhues
Subject: Re: M4 syntax $11 vs. ${11}
Date: Wed, 31 Jan 2007 20:18:36 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Eric,

Allow me to address specific points only, rather than the larger picture
of where to finally go.

* Eric Blake wrote on Tue, Jan 30, 2007 at 02:04:51PM CET:
> According to Ralf Wildenhues on 1/29/2007 11:44 AM:
> > The Coding Style ends up being inconsistent with
> >   $[#]                  where it's necessary to quote the hash,
> You missed the earlier line that recommended address@hidden:@] instead of 
> $[#] for
> the sake of syntax highlighting, even though both have the same effect.


> >   $[1]                  where either character could be quoted,
> >   [$]{1...}  vs.  $[{1...}]  vs.  $[{]1...}
> >                         where the first is inconsistent with the
> >                         previous examples, and the others are ugly,
> What about a slightly different approach:
> When in a single-quoted context, use an empty quote to separate the $ from
> the next character:
> AC_FOO([ address@hidden:@ ])    to avoid $# as well as comment, use a 
> quadrigraph
> AC_FOO([ $[]1 ])       instead of $1
> AC_FOO([ $[]{1...} ])  instead of ${1...}
> and when in a double-quoted context (less common, since we recommend one
> level of quotes per parentheses), use an inverted empty quote to break the
> string into two parts:
> AC_FOO([[ $][# ]])   no quadrigraph necessary
> AC_FOO([[ $][1 ]])
> AC_FOO([[ $][{1...} ]])

Barring all other questions, this looks consistent to me.

> > IMHO, it's not a good idea to not "practice what we preach" in any
> > direction: either have the code be more cautious than the documentation,
> > or vice versa.
> Unfortunately, I think existing code in autoconf alone is full of several
> styles.  Would it be worth my time to also prepare a mechanical patch that
> tries to convert existing uses into a single style?

I'd probably be in the "only for new code, follow this" boat, to provide
bug-for-bug compatibility with buggy user scripts.

> Or maybe we just give up, and flat out document that as long as autoconf
> supports both M4 1.4.x and 2.0 simultaneously, m4's --warn-syntax option
> must not be used.  Then only the line in m4sugar that uses changesyntax to
> cripple M4 2.0's ${1} parsing is needed, and we can ignore false
> positives.

Is that even true?  What about code that is read before AC_INIT?  What
about code that uses `define' not `m4_define'?

I tried your warnings now:

cat >aclocal.m4 <<\EOF
AC_DEFUN([Y], [${1}])
define([Z], [${1}])
cat > <<\EOF
AC_DEFUN([X], [${1}])
M4=m4\ --warn-syntax autoconf
| m4:aclocal.m4:1: Warning: semantics of `${1...}' in `Y' will change

Why do I get only one warning, and only get the next one, once I fix the
first?  Fixing one-by-one is very frustrating for users.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]