[Top][All Lists]

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

Re: RFC: m4 2.0 --prepend-include option

From: Paul Eggert
Subject: Re: RFC: m4 2.0 --prepend-include option
Date: Wed, 23 Aug 2006 10:59:44 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Eric Blake <address@hidden> 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.

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.

> 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 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

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.

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.

I don't understand (2); it doesn't seem to be documented.  Does it
really need to depend on POSIXLY_CORRECT.

For (3) perhaps we can ask POSIX to allow the GNU behavior; then
we can remove the POSIXLY_CORRECT dependency.

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

> 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.

reply via email to

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