From owner-svn-src-all@freebsd.org Sat Aug 1 19:24:23 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2477C9B0EAB; Sat, 1 Aug 2015 19:24:23 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE28D1E44; Sat, 1 Aug 2015 19:24:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 2DABB358C59; Sat, 1 Aug 2015 21:24:20 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 1215B28494; Sat, 1 Aug 2015 21:24:20 +0200 (CEST) Date: Sat, 1 Aug 2015 21:24:20 +0200 From: Jilles Tjoelker To: Bruce Evans Cc: Baptiste Daroussin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285985 - in head/usr.sbin/pw: . tests Message-ID: <20150801192419.GB94932@stack.nl> References: <201507282110.t6SLAx0k035167@repo.freebsd.org> <20150729080932.S5059@besplex.bde.org> <20150801133629.GA94932@stack.nl> <20150802022204.O3247@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150802022204.O3247@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 19:24:23 -0000 On Sun, Aug 02, 2015 at 02:59:00AM +1000, Bruce Evans wrote: > On Sat, 1 Aug 2015, Jilles Tjoelker wrote: > > These values are easily written using arithmetic expansion, for example > > largeid=$((0x100000000)). > Not really. Shells are also very buggy or limited in this area. I > often use old versions of sh and bash that only support up to INT32_MAX > and have broken overflow handling. /bin/sh in -current only supports > up to INT64_MAX (or maybe INTMAX_MAX) and has broken overflow handling > (it clamps to INT64_MAX). Not so old versions of bash only support > up to INT64_MAX and have differently broken overflow handling (4.3.99 > blindly assigns to int64_t, so $((0x8000000000000000)) becomes > -0x8000000000000000. > expr is also limited to INT64_MAX, but attempts to have non-broken > overflow handling. The tests need not work with old versions of sh and bash (they already rely on many more recent features and bugfixes). The broken overflow handling in parsing literals does not affect the given example. > > When using strtol() or similar functions, accepting hex typically > > implies accepting octal as well, which causes confusing and > > POSIX-violating results like 010 interpreted as eight. > This is a problem. strtonum could accept hex but not octal by calling > strtoimax() twice for bases 10 and 16. Also dehumanized formats like > 1k and 1K. It should also actually accept numbers as input. 1.1e1 if > not I * Pi. Silently expanding what strtonum() accepts might cause breakage or even security vulnerabilities. -- Jilles Tjoelker