[patch] Re: standards/52972: /bin/sh arithmetic not POSIX compliant

[Wartan Hachaturow]

The following reply was made to PR standards/52972; it has been noted by GNATS.

From: Wartan Hachaturow <wart at tepkom.ru>
To: Jens Schweikhardt <schweikh at schweikhardt.net>
Cc: freebsd-gnats-submit at freebsd.org
Subject: [patch] Re: standards/52972: /bin/sh arithmetic not POSIX compliant
Date: Thu, 3 Jul 2003 18:27:53 +0400

 Hello.
 
 I've hacked out a simple patch for 5.1-RELEASE's /bin/sh, implementing 
 variables support in arithmetic evaluation, along with various assignment
 operators.
 
 Since the patch is pretty big (11k), I won't include it right in the letter,
 it may be grabbed from
 http://velvet.myxomop.com/~wart/ash.patch
 
 
 Below are some comments to the patch:
 First of all, arithmetics variables are plain shell variables, without any 
 integer/string variable difference. If the variable doesn't exist, it is 
 initialized to zero, as SUS requires. When integer value is needed, the
 result
 of lookupvar() is strtol'ed. Austin group's proposed change to the
 standart 
 says that the behaviour in case of unconvertable string is unspecified.
 I try to avoid the case of "1ab" being silently converted to integer 1,
 and check that. There's one miss, though -- just like bash, we skip 
 initial whitespaces in the variable (inside strtol):
 
 $ a="   1"
 $ echo $((a+1))
 2
 
 I don't consider this being clever, but I didn't find the way to avoid
 it
 (after all, results are unspecified :).
 Integer to string coversion is performed via snprintf.
 SUS now requires us to have at least signed long arithmetics. I've tried
 to make the code type-independent, and introduced an arith_t typedef
 (is it ok with style(9)?) with the macros for strtoarith_t and
 atoarith_t.
 11 assignment operators are implemented, following SUS requirement.
 I haven't found a test suite for shell arithmetics, but simple things 
 like
 
 $ i=1; j=2; k=3
 $ echo $((i+=j+=k))
 6
 $ echo $i, $j, $k
 6, 5, 3
 
 work so far. If anyone would submit a test suite, I'll be glad to test
 it.
 Only decimal-base arithmetics is implemented. Thus, x=010 is being
 treated
 as decimal 10. I've browsed SUS, trying to find the requirement for
 other
 bases, but haven't found it. Should we support it?
 
 Comments, fixes, bugs, blames, etc. are welcome.
 
 -- 
 Regards, Wartan.
 "Computers are not intelligent. They only think they are."