-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [dropping autoconf]
According to Paul Eggert on 8/23/2006 11:59 AM: > Eric Blake <[EMAIL PROTECTED]> writes: > >> So by that proposal, a user could then do 'POSIXLY_CORRECT=1 m4 >> -B1024' to get the same behavior with GNU or Solaris m4, regardless >> of the presence of ./1024, because path searches would be disabled >> in the GNU version thanks to the implicit -G. > > This doesn't sound right. POSIXLY_CORRECT is supposed to do just one > thing: change behavior where GNU applications are incompatible with > POSIX. It is not supposed to disable extensions that are compatible > with POSIX, nor is it supposed to affect compatibility with > traditional behavior not specified by POSIX. Agreed. > > Since POSIX does not specify the behavior of m4 -B, we can define m4 > -B to mean whatever we like, independently of whether POSIXLY_CORRECT > is set. >> If I make -B a synonym for --prepend-include, > > Why -B? Can't you use a different letter? > > Or why not just leave it alone? It's unlikely people will use this > option when invoking M4 by hand, so the benefit of a short name for it > is fairly small. > autom4te already uses -B as a synonym for --prepend-include, modeling it after gcc's -B. I guess it boils down to whether m4 2.0 should strive for a command-line compatible interface with other existing m4 implementations, or whether we tell users that to get compatible behavior, they have to write a wrapper shell script around m4 that loads the correct m4 module which provides the semantics of the other implementation. I'm leaning towards defining -B to always mean --prepend-include, and nuking - -S and -T support (the other two arbitrary limit tweaking parameters of Solaris m4) rather than leaving them in as undocumented no-ops. But I'd still like to hear Gary's opinion as an official m4 maintainer, before checking in my proposed patch (or slight modification thereof). > > >> I would rather see POSIXLY_CORRECT imply -G, add an option -g >> (--gnu) to override it (and some BSD versions already have -g to >> turn on GNU compatibility), and then base all compatibility >> decisions solely on whether -G is in effect. > > That would be fine, but the behavior of --prepend-include should not > be affected by POSIX compatibility decisions. We want POSIXLY_CORRECT > to affect behavior as little as possible. So if you go this > direction, -G should not disable GNU extensions; it should merely act > like POSIXLY_CORRECT does, and disable _incompatible_ GNU extensions. > > Most GNU applications do not have an option to disable all GNU > extensions. Such an option has only a small benefit to the GNU > project, and nobody uses these options except perhaps for some POSIX > nerds. (I'm a POSIX nerd, and I don't use them, so my guess is that > the size of the audience is zero. :-) I see what you mean - if someone really wants their m4 script to be portable to other implementations, they will only use what POSIX specifies, rather than relying on non-POSIX extensions (whether they be from GNU m4, or extensions from another implementation such as Solaris' -B parameter). Which is why I'm trying to consolidate no_gnu_extensions and posixly_correct into a single switch (right now, -G already turns on both booleans), and minimize what that switch changes, in order to simplify the effort of testing the effect of the switch on other features. > > I think it would be fine if you removed -G from M4; there's no > particular reason to pollute the option space to worry about POSIX > compatibility issues. Or if you want to keep -G, it would be fine to > silently ignore it, or to change it to mean "disable incompatible > extensions" (i.e., behave like POSIXLY_CORRECT) rather than "disable > all extensions". But in the long run it'd be simplest to just remove > it. > > While we're on the subject..... > > Looking at the code, POSIXLY_CORRECT now affects the following > behaviors of CVS M4: > > 1. Multidigit arguments of $, e.g., $10. > 2. Value arg signatures, whatever they are. > 3. Whether 'define' implies 'undefine' or 'popdef'. > 4. Whether 'undivert' accepts a non-numeric argument. > 5. Whether options can follow operands in the command line. > > In XCU ERN 111 you asked for changes to POSIX so that (1) would be > allowed as a compatible extension; if this is accepted, we can change > M4 so that it supports (1) even if POSIXLY_CORRECT is defined. Right now, the only way to affect (1) is via the initial environment; there is no way for a module to override the parser. But unconditionally supporting it was my goal in writing the aardvark. > > In XCU ERNs 99 and 101 you asked for similar changes for (4), and they > have been accepted by the Open Group. In situations like these I > think it's fine to drop the POSIXLY_CORRECT check; that is, the code > can do (4) without worrying about POSIXLY_CORRECT. It's OK to > anticipate the next version of POSIX in relatively-minor situations > like these. (3) and (4) could also be solved by writing a module to redefine those macros with posix-compliant implementations, rather than relying on the global state from the command line. > > I don't understand (2); it doesn't seem to be documented. Does it > really need to depend on POSIXLY_CORRECT. I wasn't either, and after some sleuthing, found this: http://lists.gnu.org/archive/html/m4-patches/2003-06/msg00002.html It looks like an incomplete patch (intentionally tabled until post 2.0) to allow named parameters. Perhaps a better thing to do here would be use a syntax like: define(`foo{bar, baz}', `arg2: ${baz}, arg1: $1') foo(a, b) => arg2: b, arg1: a ie. invent a new syntax type for named argument delimiters (here, `{' and `}'). Then we are completely compatible with POSIX, because { is not part of a valid macro name, and ${ does not have required semantics. We could even hook it into the changesyntax builtin, so that autoconf can continue to use macro names of [foo(bar)] without confusing it with named parameters, as in Gary's original writeup. But I also agree with Akim's retort that such a feature must be post 2.0, and ensure it doesn't break existing m4 clients. > > For (3) perhaps we can ask POSIX to allow the GNU behavior; then > we can remove the POSIXLY_CORRECT dependency. Actually, for (3), I'm not even sure POSIX has an opinion one way or the other - it is only the NEWS file of GNU m4 that claims that POSIX required the undefine() behavior, since that was the implementation choice made by other implementations. > > For (5) we can perhaps do the same as (3), but this is a bigger deal > since it affects lots of programs, and perhaps I should attempt that > (if you want to pursue it) since I know better where the bodies are > buried. I thought (5) has already been attempted; at least discussions have been raised about the issue on the Austin mailing list. And I am not as worried about it, because it is the gnulib getopt implementation that would be affected and not the m4 code base proper. Other places where I know GNU is currently incompatible with POSIX, but where POSIXLY_CORRECT does not (yet) have an effect: (6) GNU accepts character ranges in `translit', although I intend to file an aardvark to allow this extension (7) GNU treats many builtins as blind (ie. `eval' without arguments expands to `eval', not `0'), but I don't know if an aardvark is worth it, as it affects quite a few of the builtins (8) GNU treats `maketemp' more like mkstemp(3); I have already filed an aardvark (9) GNU uses traditional m4 operator precedence in `eval' instead of C precedence; here I plan to fix GNU and the things currently affected by no_gnu_extensions instead of posixly_correct: (10) whether file inclusion searches a path; seems like a clean extension of POSIX to me, and should not be conditional (11) whether macro tracing survives the macro being undefined; seems like a clean extension to me, and should not be conditional (12) whether the 'traditional' or 'gnu' module is loaded at startup (13) whether `m4wrap' takes multiple arguments Of those, 6, 7, 8, 9, 12, and 13, seem like they can all be addressed by a module. In other words, a POSIX nerd could theoretically implement a POSIX m4 by a simple wrapper script and a (not yet written) posix module: #!/bin/sh export POSIXLY_CORRECT=1 exec /path/to/gnu/m4 -m posix "$@" - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE7MoQ84KuGfSFAYARAs+aAJ4m8E5AlCKBPC/G6MHSwJXqJ/PiUgCfdxw7 zC4ad9rZN7Pjam60XPekP7A= =BYD4 -----END PGP SIGNATURE----- _______________________________________________ M4-discuss mailing list M4-discuss@gnu.org http://lists.gnu.org/mailman/listinfo/m4-discuss
