Eric Blake <[EMAIL PROTECTED]> writes: > http://lists.gnu.org/archive/html/m4-patches/2003-06/msg00002.html > > 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 confusion. >> 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 Sounds good. > (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 suchlike. > (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: > #!/bin/sh > 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. _______________________________________________ M4-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/m4-discuss
