1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
//! Human-readable byte-count rendering.
//!
//! Lives here, not in the CLI, so a codec's `--memory-limit` refusal message
//! and `stuffr info`'s resolved-limit display share one formatter rather than
//! inventing their own — see the whole-branch review's LOW-5 finding: before
//! this, the same quantity (a declared or configured memory bound) appeared
//! as raw **bytes** (`xz_pure.rs`, `lzip.rs`), **KiB** (`lzma_pure.rs`), and
//! **MiB/GiB** (`stuffr info`) in the same build, which is exactly backwards for
//! the one message a user reads to decide what to pass back to
//! `--memory-limit`.
//!
//! `stuffr-cli`'s `size::parse_size` is the inverse and stays in the CLI
//! crate — it is flag-syntax (`512M`, `2G`), not a general utility, and this
//! crate has no reason to know what a command-line flag looks like. This
//! function has no such reason to live above `stuffr-core`: it is pure
//! arithmetic, with no format dependency, so codecs in `stuffr-formats` can
//! use it directly for their own refusal messages.
/// Renders a byte count the way a human reads it.
///
/// Exact multiples get a bare suffix (`256 MiB`); anything else keeps one
/// decimal (`1.5 GiB`), because rounding a limit or a declared size to a tidy
/// figure would be actively unhelpful in a message someone is using to size
/// a flag.