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

Cheers,
        Gary
--
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

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