Date: Thu, 3 Jul 2003 07:30:17 -0700 (PDT) From: Wartan Hachaturow <wart@tepkom.ru> To: freebsd-standards@FreeBSD.org Subject: [patch] Re: standards/52972: /bin/sh arithmetic not POSIX compliant Message-ID: <200307031430.h63EUHGI053167@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR standards/52972; it has been noted by GNATS. From: Wartan Hachaturow <wart@tepkom.ru> To: Jens Schweikhardt <schweikh@schweikhardt.net> Cc: freebsd-gnats-submit@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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307031430.h63EUHGI053167>