From owner-freebsd-standards@FreeBSD.ORG Thu Jul 3 07:30:19 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08BBC37B401 for ; Thu, 3 Jul 2003 07:30:19 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F25A43FEC for ; Thu, 3 Jul 2003 07:30:18 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h63EUIUp053168 for ; Thu, 3 Jul 2003 07:30:18 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h63EUHGI053167; Thu, 3 Jul 2003 07:30:17 -0700 (PDT) Date: Thu, 3 Jul 2003 07:30:17 -0700 (PDT) Message-Id: <200307031430.h63EUHGI053167@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Wartan Hachaturow Subject: [patch] Re: standards/52972: /bin/sh arithmetic not POSIX compliant X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Wartan Hachaturow List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 14:30:19 -0000 The following reply was made to PR standards/52972; it has been noted by GNATS. From: Wartan Hachaturow To: Jens Schweikhardt 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."