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(100) },
{ "G", UINT64_C(10) },
{ "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
__
POPT Library http://rpm5.org
Developer Communication List [email protected]
