Re: bad define semantics in GNU m4

[Paul Eggert]

"Gary V. Vaughan" <address@hidden> writes:

> In which case, I propose the small attached patch.  Comments?

This patch conflates two somewhat-different notions.

First, GNU m4 already has a way to emulate traditional m4, by
suppressing GNU extensions.  This is "m4 --traditional", which is akin
to "gcc -traditional".

Second, this email thread suggests that GNU m4 should conform to POSIX
if the user asks for it, by suppressing GNU extensions that are
incompatible with POSIX.  m4 already does this to a minor extent, as
it uses the POSIXLY_CORRECT environment variable to decide whether use
POSIX rules when parsing command-line options.  This behavior would be
akin to "gcc -ansi", which causes GCC to disable extensions that are
incompatible with the C Standard.

The proposed patch doesn't entirely fix the POSIX conformance problem,
since it confuses the two notions.

How about if we modify m4 so that it disables incompatibilities with
POSIX if the POSIXLY_CORRECT environment variable is set?  This is
what the GNU coding standards suggest.  (We could also add a new
option "m4 --posix" to do this as well, if you like, though I think
this wouldn't be as useful for testing portable shell scripts.)

If this idea seems good to you, I can propose a revised patch along
these lines.