svn commit: r285985 - in head/usr.sbin/pw: . tests

[Jilles Tjoelker]

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