RPM Community Forums

Mailing List Message of <popt-devel>

Re: Permit arg units (like 100Kb), add getdate?

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 02 May 2008 - 14:00:56 CEST
Message-Id: <FD317D99-6486-4521-8633-324814B833E9@mac.com>

On May 2, 2008, at 2:24 AM, Ralf S. Engelschall wrote:

> On Thu, May 01, 2008, Jeff Johnson wrote:
>
>> While using popt in another program, I came across 2 usage
>> cases that might be usefully internalized in popt.
>>
>> One usage case was an attempt to specify a memory limit as
>>     --memory 16777216
>> Adding unit scaling, e.g.
>>     --memory 16Mb
>>     --memory 16384Kb
>> would not be hard to add using something like
>>     POPT_ARG_INT | POPT_ARGFLAG_UNITS
>> with the usual Kb/Kib Mb/Mib Gb/Gib tokens to prescale.
>>
>> Another possible popt-1.15 usage case is getdate.y, which is  
>> wonderfully
>> useful for time/date argument input. While it is
>> rather easy to use getdate.y through a popt callback, perhaps
>> its time to push getdate.y into libpopt, and add a
>>     POPT_ARG_DATE
>> distinguished method to make it as easy as possible to use getdate.y.
>>
>> I'm also seeing a need for a KEY=VALUE comma separated list popt
>> sub-table option parser (there's a mouthful ;-)
>>
>> I'm starting to see
>>     --option K1=V1,K2=V2,K3=V3
>> occurrences more often. I can think of a couple ways to use popt
>> to recursively parse KEY=VALUE settings, either by keeping track
>> of a chained popt table that is used iff a specific --option is
>> encountered,
>> or by overloading the pointer field to be used as a option specific
>> subtable parse.
>>
>> Opinions?
>
> The --option K1=V1,K2=V2,K3=V3 is generic and would be very useful  
> IMHO.
>
> But the unit and date parsing is something I think should be perhaps
> still better done in the application (or the POPT callback) because
> where is the end of this story? If POPT provides units and dates,
> someone else comes and wants URL arguments pre-parsed into its parts,
> that user/group names are converted to user ids and vice versa, that
> chmod(8) strings are converted to octals and vice versa, etc. Either
> POPT would have to provide a really large set of those conversions are
> better none at all. Additionally, if POPT provides those  
> conversions it
> perhaps better should be at least placed into a POPT sub-library so  
> that
> one still can have a rather small plain POPT library and if  
> required and
> wished one can link against the additional POPT "utility" library for
> addon functionalities like those conversions...
>

See what is implemented in LZMA lzma/src/lzma/util.c str_to_uint64()
for what motivated the unit scaling suggestion. A table like

                 static const struct {
                         const char *name;
                         uint64_t multiplier;
                 } suffixes[] = {
                         { "k",  UINT64_C(1000) },
                         { "M",  UINT64_C(1000000) },
                         { "G",  UINT64_C(1000000000) },
                         { "Ki", UINT64_C(1024) },
                         { "Mi", UINT64_C(1048576) },
                         { "Gi", UINT64_C(1073741824) },
                         { NULL, 0 }
                 };

to do scaling of an integer, or handling the [min,max] range check
in str_to_uint64() with a table instead of arguments is what I  
contemplated. A table
driven parse and multiply is not much different than a table driven
parse and set for "K=V" strings, particularly since the popt 7-tuple
is likely to be abused for the subtables.

Multiplying or comparing integers is quite general, and a very different
problem space than slicing URI's or converting user id's, or handling  
mode
arguments (which could be parsed using %b format if tokens were fixed  
length
single chars w/o ',' separators, but I digress ...)

Parsing dates is definitely tricky, which is the reason why getdate.y  
was originally written.
The rationale for adding to popt is largely to make getdate.y more  
widely available.

Yet Another Library to multiply/compare integers, or to handle the  
addition
of a single routine like getdate.y seems overkill.

Thanks for comments.

73 de Jeff
Received on Fri May 2 14:01:47 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.