Re: POSIX vs. eval

[Gary V. Vaughan]

Hi Eric,

On 28 Dec 2006, at 14:41, Eric Blake wrote:

The current wording of the m4 eval macro forbids implementations from
providing the , and  ?: operators as extensions, even though these
operators could reasonably be implemented (all of the other forbidden
operators involve C language constructs that are not available with
strict numerical evaluations).  The BSD implementation of M4 already
provides ?:.

Agreed.  As long as extensions are labeled as such for each
implementation, the onus is on the user to decide whether to
use the extension and lock their code in, or ignore the extensions
in exchange for having portable code.

I think the only change in the POSIX wording would be to remove
the forbid aspect, and instead list all the required operators.

The wording also requires signed 32-bit arithmetic as well as the shift

operators, even though the C standard states that there is undefined
behavior when shifting signed numbers in certain manners.  The C
standard also states that / or % by 0 is problematic, and different

result in an empty expansion.  And not all implementations correctly
short-circuit && or || when the dead branch contains a division by 0.

implementations vary on whether they crash, issue an error, or silently

Not so sure about this one.  It seems ugly to say that a compliant
implementation of m4 will behave as per the underlying C runtime in
the cases you raise.  On the other hand it seems harsh to require
particular behaviour that makes the implementation unnecessarily
complicated when stricter requirements don't match the C runtime.

Meanwhile, mandating 32-bit arithmetic is a bit harsh, since the BSD
implementation uses int (which may be larger or smaller than 32 bits

1.4o used 64-bit arithmetic.

when compiled on various architectures), and the beta release of GNU M4

Maybe, "at least 32-bit arithmetic"?

Also, many implementations provide ** as an exponentiation operator,
with right-associativity and precedence between unary + and binary *
(at least Solaris, GNU, and BSD), while older implementations used ^
to mean exponentiation rather than exclusive-or.

It seems sensible to follow the modern implementations in this case.

And not all existing implementations follow C precedence: Solaris, and

and gave ! and ~ lower precedence than == rather than equal precedence
with unary + and -; and Solaris gives | equal, rather than lower,
precedence with ^.

GNU 1.4.x and earlier, gave == and != the same precedence as < > <= >=,

That sounds like an implementation bug then.  It's not unreasonable
to require strict C precedence rules.  Pragmatic programmers will
use parentheses defensively anyway, so POSIX is IMHO free to specify
whatever precedence rules they like (within reason).

Cheers,
        Gary
--
Gary V. Vaughan      ())_.  [EMAIL PROTECTED]
Research Scientist   ( '/   http://blog.azazil.net
GNU Hacker           / )=   http://www.gnu.org/software/{libtool,m4}
Technical Author   `(_~)_   http://sources.redhat.com/autobook

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
M4-discuss mailing list
M4-discuss@gnu.org
http://lists.gnu.org/mailman/listinfo/m4-discuss