[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: POSIX vs. eval

From: Gary V. Vaughan
Subject: Re: POSIX vs. eval
Date: Fri, 29 Dec 2006 20:27:46 +0000

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
implementations vary on whether they crash, issue an error, or silently
result in an empty expansion.  And not all implementations correctly
short-circuit && or || when the dead branch contains a division by 0.

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
when compiled on various architectures), and the beta release of GNU M4
1.4o used 64-bit arithmetic.

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
GNU 1.4.x and earlier, gave == and != the same precedence as < > <= >=,
and gave ! and ~ lower precedence than == rather than equal precedence
with unary + and -; and Solaris gives | equal, rather than lower,
precedence with ^.

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).

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]