[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: m4 2.0 --prepend-include option
Re: RFC: m4 2.0 --prepend-include option
Wed, 23 Aug 2006 15:43:32 -0700
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
Eric Blake <address@hidden> writes:
> It looks like an incomplete patch (intentionally tabled until post 2.0)
That's fine, but why does it depend on POSIXLY_CORRECT? If the change
is tabled, perhaps it should just be disabled in all cases, to avoid
>> 3. Whether 'define' implies 'undefine' or 'popdef'.
>> 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,
I just now read the POSIX spec and I agree with you: it does not
clearly state the behavior one way or the other. Therefore GNU m4 can
and should do it the "right" way, regardless of POSIXLY_CORRECT. Or,
if you want to be more conservative about this, we can ask for a
ruling that this is OK (I'm pretty sure the answer will be "yes" given
the longstanding default behavior of GNU M4).
> 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
Well, I suppose I could put it on my list of things to do. :-)
Admittedly it's low priority.
> (10) whether file inclusion searches a path; seems like a clean extension
> of POSIX to me, and should not be conditional
Yes. It is a pure extension if the user specifies a -B option or
> (11) whether macro tracing survives the macro being undefined; seems like
> a clean extension to me, and should not be conditional
Yes. It seems to me POSIX does not specify the behavior here so we
can do what we like.
> (12) whether the 'traditional' or 'gnu' module is loaded at startup
What is the significance of this? If it's merely a matter of which
macros are builtin, I think POSIX allows M4 to predefine whatever
extra macros it likes (though obviously this shouldn't be overdone).
Solaris 10 m4, for example, predefines the macro 'unix'. So if it's
just a macro visibility issue, POSIXLY_CORRECT shouldn't matter here.
> (13) whether `m4wrap' takes multiple arguments
Perhaps an Aardvark should be filed for this as well?
> a POSIX nerd could theoretically implement a
> POSIX m4 by a simple wrapper script and a (not yet written) posix module:
> export POSIXLY_CORRECT=1
> exec /path/to/gnu/m4 -m posix "$@"
By "POSIX m4" you mean an M4 that supports only POSIX features, and
nothing else? I don't think this is worth our worrying about.
But if you mean an M4 that conforms to POSIX, then it shouldn't be
that complicated; setting POSIXLY_CORRECT alone should suffice to
conform to POSIX. But it'd be fine if POSIXLY_CORRECT implied -m
posix, where we supply the posix module.
> autom4te already uses -B as a synonym for --prepend-include, modeling it
> after gcc's -B.
Ah, OK. In that case, I suggest changing GNU m4 -B to be consistent
with the other GNU programs. Even if someone uses the SunOS syntax
(which I think is rare), it'll still work, unless they have a
directory whose name consists entirely of digits, which is quite
unlikely. The only package I know of that uses SunOS "m4 -B" is
OpenSSL (it uses "m4 -B 8192), and its use is safe in this respect.
I expect others are similar.
> nuking -S and -T support (the other two arbitrary limit tweaking parameters of
> Solaris m4) rather than leaving them in as undocumented no-ops.
OK. A more-conservative approach would be to put in warnings that
they're going to be removed in a future version. I don't know of
anything using either -S or -T, but there's no rush deleting them.
multidigit arguments [was: RFC: m4 2.0 --prepend-include option], Eric Blake, 2006/08/24
Re: RFC: m4 2.0 --prepend-include option, Eric Blake, 2006/08/25