| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Correct an out of bounds read with HN_AUTOSCALE and very large numbers.
The maximum scale is 6 (K, M, G, T, P, E) (B is 0).
Overly large explict scales were checked correctly, but for sufficently
large numbers HN_AUTOSCALE would get to 7 resulting in an out of bounds
read.
Found with humanize_number_test and CHERI bounds checking.
Reviewed by: emaste
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since so many programs don't check return value, always NUL terminate
the buf...
fix rounding when using base 1024 (the bug that started it all)...
add a set of test cases so we can make sure that things don't break
in the future...
Thanks to Clifton Royston for testing and the test program...
Approved by: re (hrs, glebius)
MFC after: 1 week
|
|
|
|
|
|
| |
PR: bin/171487
Submitted by: matthew
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
prefixes (Ki, Mi, Gi...) for humanize_number(3).
Note that applications has to pass HN_IEC_PREFIXES to use this
feature for backward compatibility reasons.
Reviewed by: arundel
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer overflow when the input is very large (for example, 100 Pi would
become about 10 Ei which exceeded signed int64_t).
Solve this issue by splitting the division into two parts and avoid the
multiplication.
PR: bin/146205
Reviewed by: arundel
MFC after: 1 month
|
|
|
|
|
|
|
| |
(humanize_number.3 intentionally hold back until I make sure why we didn't
merged dehumanize_number(3)).
Obtained from: NetBSD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Significant changes:
- rev. 1.11: Use PRId64 instead of a cast to long long and %lld to print
an int64_t.
- rev. 1.12: Fix a bug that humanize_number() produces "1000" where it
should be "1.0G" or "1.0M". The bug reported by Greg Troxel.
PR: 118461
PR: 102694
Approved by: rwatson (mentor)
Obtained from: NetBSD
MFC after: 1 month
|
|
|
|
| |
Obtained from: NetBSD
|
|
readable form.
Obtained from: NetBSD
|