bug-m4
[Top][All Lists]
Advanced

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

Re: Remaining non-blind macros


From: Gary V. Vaughan
Subject: Re: Remaining non-blind macros
Date: Mon, 10 Jul 2006 13:52:52 +0100
User-agent: Thunderbird 1.5.0.4 (Macintosh/20060530)

Hi Eric!

Eric Blake wrote:
> According to Gary V. Vaughan on 7/10/2006 3:55 AM:
>>> Eric Blake wrote:
>>>> I just looked at the list of blind macros (those that must be
>>>> passed arguments to be recognized, such as define), and had
>>>> a couple of questions.  Most of the builtins that are not blind
>>>> have a reason; for example, dnl would be worthless if it were
>>>> blind.  And I already recently changed indir and format to be
>>>> blind.  However...
> 
> indir and format are GNU extensions, after all, so we have a bit more
> freedom in their definitions.

Agreed. :-)

>>>> Any reason that shift is recognized even without arguments?
>>> The only reason I can imagine is for compatibility with other
>>> implementations.  The stable branch shouldn't change the status
>>> quo, unless there is an actual (or at least potential) bug...
>>> however, if you can find another (popular!) implementation of
>>> M4 that has a blind shift macro, then our non-blind shift is
>>> definitely buggy! :-)
> 
> I don't have easy access to a BSD implementation of m4 right now, but I
> just noticed on
> http://www.freebsd.org/cgi/man.cgi?query=m4&sektion=1&apropos=0&manpath=freebsd
> that they document having blind macros (but don't mention whether shift
> and m4wrap are included in their list of blind macros).

We could just ask on their mailing list (assuming they have one)?  BSD
M4 is not necessarily a good example of an independent implementation
though, as they have the goal of being able to support autoconf, and
thus may have been led astray by the GNU implementation ;-)

Note that the manual page you quote also says:

        All built-ins do expand without arguments in many other m4
        implementations.

My inclination is to leave branch_1-4 as is, unless we receive (or
can make) a bug report to the contrary

> I also noticed
> they add the builtins expr (alias for eval), paste and spaste (where paste
> is comparable to undivert(name)), and the command-line option -g; for
> compatibility, we support support these features.  They have also copied
> indir, but not format.

For HEAD, it would be relatively straight forward to write a bsd module
that adds support for these builtins.

> The way I envision things for CVS head is that all builtins that aren't
> explicitly documented to have special behavior with 0 arguments should be
> blind in gnu mode, and follow POSIX behavior in traditional mode.

Agreed.

> Besides, it is easy enough to make a macro blind:
> define(`shift', `ifelse(`$#', `0', ``$0'', `builtin(`$0', $@)')')

Except when you are trying to make a bunch of macros written for another
M4 implementation work properly, and you don't know about such things
;-)  But, yes, you are right... I'm just being pedantic... it is Monday
after all :-D

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://blog.azazil.net
GNU Hacker           / )=   http://trac.azazil.net/projects/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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