Date: Sun, 2 Aug 2015 14:44:44 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: Bruce Evans <brde@optusnet.com.au>, Baptiste Daroussin <bapt@freebsd.org>, 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: <20150802141200.G894@besplex.bde.org> In-Reply-To: <20150801192419.GB94932@stack.nl> References: <201507282110.t6SLAx0k035167@repo.freebsd.org> <20150729080932.S5059@besplex.bde.org> <20150801133629.GA94932@stack.nl> <20150802022204.O3247@besplex.bde.org> <20150801192419.GB94932@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Aug 2015, Jilles Tjoelker wrote: > 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. But I complained about the example being deficient. It only needs to test up to UINT32_MAX now, but that may change. A similar test in dd already needs to go up to UINT64_MAX. dd does support hex numbers, and is suppose to support offsets about OFF_MAX, but this is broken by excessive support for the signedness of off_t. All kernel addresses in /dev/kmem are above 0xffffffff00000000 on amd64. I tried to get green@ to fix this in Y2K, but the result was a larger mess. >>> 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. It is hard to fix broken APIs/UIs once they are used. strtonum() is not used often in /usr/src. Its main use is in openssh, and that is hard to fix since both strtonum and opensh are from OpenBSD. Using names in the reserved namespace causes portability problems. FreeBSD's expand_number() is a much worse name, but at least it doesn't conflict with better future uses of a reserved name. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150802141200.G894>