Next: Other Incompatibilities Prev: Extensions Up: Compatibility

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' (Note: 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' (Note: 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')' (*note
     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' (Note: 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

   * At one point, POSIX required `changequote(ARG)' (*note
     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,)' (Note: 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

   * Most implementations of `m4' give macros a higher precedence than
     comments when parsing, meaning that if the start delimiter given to
     `changecom' (Note: 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' (*note
     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' (Note: 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 (Note: Debug Levels).

   * POSIX requires `eval' (Note: 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' (Note: 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 (Note: 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'.

automatically generated by info2www