POSIX vs. eval

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to prepare an aardvark to fix the POSIX wording of eval.  The
current POSIX wording is:

The eval macro shall evaluate its first argument as an arithmetic
expression, using 32-bit signed integer arithmetic. All of the C-language
operators shall be supported, except for:
 []
 ?>
 ++
 ??
 (type)
 unary *
 sizeof
 ,
 .
 ?:
 unary &
and all assignment operators. It shall be an error to specify any of these
operators.  Precedence and associativity shall be as in the ISO C
standard. Systems shall support octal and hexadecimal numbers as in the
ISO C standard. The second argument, if specified, shall set the radix for
the result; the default is 10. The third argument, if specified, sets the
minimum number of digits in the result. It shall be an error to specify
the second or third argument containing any non-numeric characters.


Here are my complaints:

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 ?:.

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.

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.

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.

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



My problem now is what the proposed wording should be.  Do I request
wording that allows the behavior of known implementations (such as
relaxing the precedence rules and adding a usage note that users must
specify () to get C precedence), or keep the rules tight (and make legacy
implementations non-POSIX compliant in the process)?  Any suggested
wordings I should propose?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFk9en84KuGfSFAYARAm2jAJ9lvFq19OnA0+nAL7k1Y272k5xq0gCeObXr
TuBbSjOPOWHEjRhu1VfwBJQ=
=PsTL
-----END PGP SIGNATURE-----