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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
