16.2 Facilities in System V m4 not in GNU m4

The version of m4 from System V contains a few facilities that have not been implemented in GNU m4 yet. Additionally, POSIX requires some behaviors that GNU m4 has not implemented yet. Relying on these behaviors is non-portable, as a future release of GNU m4 may change.

• POSIX requires support for multiple arguments to defn, without any clarification on how defn behaves when one of the multiple arguments names a builtin. System V m4 and some other implementations allow mixing builtins and text macros into a single macro. GNU m4 only supports joining multiple text arguments, although a future implementation may lift this restriction to behave more like System V. The only portable way to join text macros with builtins is via helper macros and implicit concatenation of macro results.
• POSIX requires an application to exit with non-zero status if it wrote an error message to stderr. This has not yet been consistently implemented for the various builtins that are required to issue an error (such as eval (see Eval) when an argument cannot be parsed).
• Some traditional implementations only allow reading standard input once, but GNU m4 correctly handles multiple instances of ‘-’ on the command line.
• POSIX requires m4wrap (see M4wrap) to act in FIFO (first-in, first-out) order, but GNU m4 currently uses LIFO order. Furthermore, POSIX states that only the first argument to m4wrap is saved for later evaluation, but GNU m4 saves and processes all arguments, with output separated by spaces.
• POSIX states that builtins that require arguments, but are called without arguments, have undefined behavior. Traditional implementations simply behave as though empty strings had been passed. For example, a`'define`'b would expand to ab. But GNU m4 ignores certain builtins if they have missing arguments, giving adefineb for the above example.
• Traditional implementations handle define(`f',`1') (see Define) by undefining the entire stack of previous definitions, and if doing undefine(`f') first. GNU m4 replaces just the top definition on the stack, as if doing popdef(`f') followed by pushdef(`f',`1'). POSIX allows either behavior.
• POSIX 2001 requires syscmd (see Syscmd) to evaluate command output for macro expansion, but this was a mistake that is anticipated to be corrected in the next version of POSIX. GNU m4 follows traditional behavior in syscmd where output is not rescanned, and provides the extension esyscmd that does scan the output.
• At one point, POSIX required changequote(arg) (see Changequote) to use newline as the close quote, but this was a bug, and the next version of POSIX is anticipated to state that using empty strings or just one argument is unspecified. Meanwhile, the GNU m4 behavior of treating an empty end-quote delimiter as ‘'’ is not portable, as Solaris treats it as repeating the start-quote delimiter, and BSD treats it as leaving the previous end-quote delimiter unchanged. For predictable results, never call changequote with just one argument, or with empty strings for arguments.
• At one point, POSIX required changecom(arg,) (see Changecom) to make it impossible to end a comment, but this is a bug, and the next version of POSIX is anticipated to state that using empty strings is unspecified. Meanwhile, the GNU m4 behavior of treating an empty end-comment delimiter as newline is not portable, as BSD treats it as leaving the previous end-comment delimiter unchanged. It is also impossible in BSD implementations to disable comments, even though that is required by POSIX. For predictable results, never call changecom with empty strings for arguments.
• Most implementations of m4 give macros a higher precedence than comments when parsing, meaning that if the start delimiter given to changecom (see Changecom) starts with a macro name, comments are effectively disabled. POSIX does not specify what the precedence is, so this version of GNU m4 parser recognizes comments, then macros, then quoted strings.
• Traditional implementations allow argument collection, but not string and comment processing, to span file boundaries. Thus, if a.m4 contains ‘len(’, and b.m4 contains ‘abc)’, m4 a.m4 b.m4 outputs ‘3’ with traditional m4, but gives an error message that the end of file was encountered inside a macro with GNU m4. On the other hand, traditional implementations do end of file processing for files included with include or sinclude (see Include), while GNU m4 seamlessly integrates the content of those files. Thus include(`a.m4')include(`b.m4') will output ‘3’ instead of giving an error.
• Traditional m4 treats traceon (see Trace) without arguments as a global variable, independent of named macro tracing. Also, once a macro is undefined, named tracing of that macro is lost. On the other hand, when GNU m4 encounters traceon without arguments, it turns tracing on for all existing definitions at the time, but does not trace future definitions; traceoff without arguments turns tracing off for all definitions regardless of whether they were also traced by name; and tracing by name, such as with -tfoo at the command line or traceon(`foo') in the input, is an attribute that is preserved even if the macro is currently undefined.

  Additionally, while POSIX requires trace output, it makes no demands on the formatting of that output. Parsing trace output is not guaranteed to be reliable, even between different releases of GNU M4; however, the intent is that any future changes in trace output will only occur under the direction of additional debugmode flags (see Debug Levels).

• POSIX requires eval (see Eval) to treat all operators with the same precedence as C. However, earlier versions of GNU m4 followed the traditional behavior of other m4 implementations, where bitwise and logical negation (‘~’ and ‘!’) have lower precedence than equality operators; and where equality operators (‘==’ and ‘!=’) had the same precedence as relational operators (such as ‘<’). Use explicit parentheses to ensure proper precedence. As extensions to POSIX, GNU m4 gives well-defined semantics to operations that C leaves undefined, such as when overflow occurs, when shifting negative numbers, or when performing division by zero. POSIX also requires ‘=’ to cause an error, but many traditional implementations allowed it as an alias for ‘==’.
• POSIX 2001 requires translit (see Translit) to treat each character of the second and third arguments literally. However, it is anticipated that the next version of POSIX will allow the GNU m4 behavior of treating ‘-’ as a range operator.
• POSIX requires m4 to honor the locale environment variables of LANG, LC_ALL, LC_CTYPE, LC_MESSAGES, and NLSPATH, but this has not yet been implemented in GNU m4.
• POSIX states that only unquoted leading newlines and blanks (that is, space and tab) are ignored when collecting macro arguments. However, this appears to be a bug in POSIX, since most traditional implementations also ignore all whitespace (formfeed, carriage return, and vertical tab). GNU m4 follows tradition and ignores all leading unquoted whitespace.
• A strictly-compliant POSIX client is not allowed to use command-line arguments not specified by POSIX. However, since this version of M4 ignores POSIXLY_CORRECT and enables the option --gnu by default (see Invoking m4), a client desiring to be strictly compliant has no way to disable GNU extensions that conflict with POSIX when directly invoking the compiled m4. A future version of GNU M4 will honor the environment variable POSIXLY_CORRECT, implicitly enabling --traditional if it is set, in order to allow a strictly-compliant client. In the meantime, a client needing strict POSIX compliance can use the workaround of invoking a shell script wrapper, where the wrapper then adds --traditional to the arguments passed to the compiled m4.