/bin/test asdf -ge 0

[James William Pye]

Here is the aardvark defect submission that I made:

---------------------------------------------------------------
7. Please describe the problem in the box below:

test asdf -ge 0
$((asdf + 1))

What constitutes a number in both of these cases, test(1) and shell
arithmetic expansion, does not appear to be specified.

This was brought to my attention when I noticed the differing
implementations. Firstly, zsh, which will return 0 on the first command,
and the arithmetic expansion will expand to 1. As opposed to
FreeBSD's--and likely BSDs in general--/bin/sh, which will cause an
error to be echoed to stderr and a non-zero result in both cases.

At first I contacted the zsh developers, as I assumed this was specified
behaviour after checking /bin/sh's and bash's test implementation. This
was not the case, and Dan Nelson on the zsh work list responded with
examples of other shells that behaved the same way as zsh. (A couple
notable examples being GNU's test and pdksh). He also said that he
believed this fell into undefined behaviour, and, therefore, zsh was not
incorrect.
I then contacted the FreeBSD-standards list to try to confirm that this
was undefined behaviour. Those who responded believed that this was
undefined, and thought that I should at least bring this question to the
austin group mailing list.

In case you are interested in the threads that led up to this
clarification request, here are their URIs:
http://www.zsh.org/mla/workers/2004/msg00937.html
http://lists.freebsd.org/pipermail/freebsd-standards/2004-September/000673.html


8. Please describe the desired action to be taken in the box below:

Clarification of what constitutes a number in XCU's test(1) and shell
arithmetic expansion, and perhaps other related locations.

Specifically, a given number should be considered valid if strtol(str,
&end, 0) accepts str as a valid number. This would allow the usage of
hexadecimal and octal numbers in test and arithmetic expansion, which is
likely a feature that would be welcomed by all.
(See
http://www.opengroup.org/onlinepubs/000095399/functions/strtol.html)

In the case of an invalid number, the utility should throw an error and
return non-zero, perhaps a standard error code for an invalid numbers
should be allocated, if one is not already. An invalid number in
arithmetic expansion should cause an error to be thrown before the
command is executed, and result in a non-zero value, and perhaps a
different value than the former so that a distinction can be made
between where the invalid number error occurred--before or during the
execution of a command.

An important note to make is the contrast between test(1) and expr(1),
where expr defines a valid integer, and test does not.
From http://www.opengroup.org/onlinepubs/000095399/utilities/expr.html:

  integer - An argument consisting only of an (optional) unary minus
followed by digits.

I also recommend that expr(1) be updated to allow hexadecimal and octal
numbers in the format that strtol(str, &end, 0) accepts, so as to be
consistent with the newly defined behaviour in test(1) and shell
arithmetic expansion.

(Props to Garrett Wollman on freebsd-standards for the notice of this
contrast!)
-------------------------------------------------------------------

I hope I wasn't a bit too ambitious with strtol(str, &end, 0).. =\

-- 
Regards,
        James William Pye
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 479 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20040910/1141ed82/attachment.bin