[ccan] [PATCH] make ccan/opt accept k, M suffixes for long-destined options

[Douglas Bagnall]

I got back round to this.  Patches follow.

On 28/04/11 16:16, Rusty Russell wrote:

> On Thu, 28 Apr 2011 14:31:54 +1200, Douglas Bagnall <douglas at paradise.net.nz> wrote:
>> It makes ccan/opt accept 'k' and 'M' suffixes for arguments destined
>> to be stored in long or unsigned long integers.  That is, these all do
>> the same thing:
>>
>> $ foo -x 5M
>> $ foo -x $((5 * 1024 * 1024))
>> $ foo -x 5242880
>> $ foo -x 5120k
>>
> [...]
> 
> Anyway, I'd call this opt_set_longval_bi (potentially with a _suffix_si
> version later if people want 10-based versions).

It seemed simple enough to handle both base 1000 and base 1024, so I
did that.

> Anyway, I looked at POSIX for guidance on what postfixes should be
> supported, and it really only specifies 'k' (1024).  Looking at the dd
> source, it supports 'k' and 'K', then MGTPE (and mgt as undocumented
> compatibility options).


Yeah. I've made the "show" functions output kMGTPE, while the "set"
functions also accept Kmgt.  

You need 64 bits for T, P, and E to make any sense, so the
calculations use long longs.  I have exposed the long-long-ness with
the likes of opt_set_longlongval_bi.  With all the combinations of
signedness, base, integer size, setting vs showing, there are 24 new
externed functions.  That seemed a bit excessive and rather boring to
write tests for, but it was hard to choose one of int, long, or long
long to drop, and would be inconsistent with the existing functions to
use exact sizes (e.g. opt_set_s64_bi).  So there you go.

> So, I'd say you'd want to do those, with an overflow check of course.
> And please implement opt_get_longval_bi (which should choose the minimum
> suffix which allows an exact specification).

I did this too (the naming scheme is actually opt_*show*_longval_bi,
not *get*).

Douglas