Patrick Steinhardt <ps@xxxxxx> writes: > We have two generic ways to parse integers in the "parse-options" > subsystem: > > - `OPTION_INTEGER` parses a signed integer. > > - `OPTION_MAGNITUDE` parses an unsigned integer, but it also > interprets suffixes like "k" or "g". > > Notably missing is a middle ground that parses unsigned integers without > interpreting suffixes. Introduce a new `OPTION_UNSIGNED` option type to > plug this gap. This option type will be used in subsequent commits. This takes a turn in a bit unexpected direction. Because the way to spell a scaled quantity is unambiguous in the sense that anything that used to be parsed with OPT_INTEGER() couldn't have had anything but "^-?[0-9]+$", an obvious alternative is to teach OPTION_INTEGER to always allow the scaling suffix if the user wants to use one, without adding a new "only numbers but this one does not even allow a sign" variant. Seriously, are there good candidates for an option where we want to absolutely refuse to take scaling suffix and insist only on a bare number?
