summaryrefslogtreecommitdiffstats
path: root/lib/libutil/expand_number.c
Commit message (Collapse)AuthorAgeFilesLines
* Further simplify the code, and update the manpage.des2010-08-151-23/+24
| | | | Submitted by: Christoph Mallon <christoph.mallon@gmx.de>
* no-op commit to note that the example given in the previous commit isdes2010-08-151-1/+1
| | | | | | | | | a very bad one, since the shift does not actually overflow. This is a better example (assuming uint64_t = unsigned long long): ~0LLU >> 9 = 0x7fffffffffffffLLU ~0LLU >> 9 << 10 = 0xfffffffffffffc00LLU ~0LLU >> 9 << 10 >> 10 = 0x3fffffffffffffLLU
* Fix the overflow test. It is possible for the result of andes2010-08-151-1/+1
| | | | | | | overflowing shift to be larger than the original value, e.g. (uint64_t)1 << 53 = 0x20000000000000 ((uint64_t)1 << 53) << 10 = 0x8000000000000000
* Simplify expand_number() by combining the (unrolled) loop with thedes2010-08-141-26/+26
| | | | | | | switch. Since expand_number() does not accept negative numbers, switch from int64_t to uint64_t; this makes it easier to check for overflow. MFC after: 3 weeks
* Add #include <inttypes.h> for the strtoimax().kib2008-07-071-0/+1
| | | | | Submitted by: Jilles Tjoelker <jilles stack nl> MFC after: 3 days
* Constify the first argument to expand_number() so that it canjb2007-11-181-1/+1
| | | | be called with a const without the compiler grisling.
* - Fix strange for loop.pjd2007-09-051-6/+16
| | | | | | | | | Reported by: phk - While here, check the unit before calculating the actually number. This way we can return EINVAL for invalid unit instead of ERANGE. Approved by: re (kensmith)
* Implement expand_number(3), which is the opposite of humanize_number(3), ie.pjd2007-09-011-0/+89
a number in human-readable form is converted to int64_t, for example: 123b -> 123 10k -> 10240 16G -> 17179869184 First version submitted by: Eric Anderson <anderson@freebsd.org> Approved by: re (bmah)
OpenPOWER on IntegriCloud