On second thought, my February 25 message on awk
<http://www.opengroup.org/austin/mailarchives/ag/msg09158.html>
may have misunderstood the committee's intent.
That message assumes that the committee intended that any changes to
the awk spec cannot alter the behavior of any usages that conform to
POSIX 1003.2-1992. This includes even weird usages like this one:
$ awk 'BEGIN {print 0x10}'
0
where POSIX 1003.2-1992 says 0x10 must be treated like (0 x10), and
awk must therefore print "0".
It is reasonable to invalidate bizarre and unlikely usages like this,
and if this is the committee's intent then it makes sense to allow awk
implementations to support C99-style floating point syntax as an
extension to POSIX. I could draft wording along this line, if there's
interest. The basic idea would be as follows:
(1) Require white space or comments between a number and a following
identifier. For example, the expression 0x10 would no longer
conform (but could be treated as a hexadecimal constant, as an
extension).
(2) When converting strings to numbers, allow other
implementation-dependent subject sequence forms even in the POSIX
locale. This would allow awk to evalute ("Inf" + 0) to yield
infinity if the implementation supports infinities; and similarly
for hexadecimal numbers. In the current standard, ("Inf" + 0)
must yield zero in the POSIX locale, but can yield infinity in
other locales, which is a bit odd if you think about it.
In both cases this blesses common existing practice.
gawk 3.1.5 does (1), and Solaris 10 nawk does (2):
$ gawk 'BEGIN {print 0x10}'
16
$ nawk 'BEGIN {print "Inf"+0}'
Inf
These behaviors suggest that the approach suggested in the February 25
message was too stringent.
|