My last check-in parses (approx.) dc(1) like
syntax to extend pre-existing functionality
for handling short/int/long/longlong bit
operations (like OR/AND/XOR) to most arithmetic
operations.
Whether you like RPN syntax (RPN is unnatural to those
used to infix parentheses as taught in 3rd grade), or
think that a RPN calculator is daft (its a means to an end imho)
are rather peripheral issues.
The extension in POPT 2.0 from bit masking to all arithmetic
operations was achieved _WITHOUT_ all this baggage in
the API:
/** \ingroup popt
* \name Arg modifiers
*/
/*...@{*/
#define POPT_ARGFLAG_ONEDASH 0x80000000U /*!< allow -longoption */
#define POPT_ARGFLAG_DOC_HIDDEN 0x40000000U /*!< don't show in
help/usage */
#define POPT_ARGFLAG_STRIP 0x20000000U /*!< strip this arg from
argv(only applies to long args) */
#define POPT_ARGFLAG_OPTIONAL 0x10000000U /*!< arg may be missing */
#define POPT_ARGFLAG_OR 0x08000000U /*!< arg will be or'ed */
#define POPT_ARGFLAG_NOR 0x09000000U /*!< arg will be nor'ed */
#define POPT_ARGFLAG_AND 0x04000000U /*!< arg will be and'ed */
#define POPT_ARGFLAG_NAND 0x05000000U /*!< arg will be nand'ed */
#define POPT_ARGFLAG_XOR 0x02000000U /*!< arg will be xor'ed */
#define POPT_ARGFLAG_NOT 0x01000000U /*!< arg will be negated */
#define POPT_ARGFLAG_LOGICALOPS \
(POPT_ARGFLAG_OR|POPT_ARGFLAG_AND|POPT_ARGFLAG_XOR)
#define POPT_BIT_SET (POPT_ARG_VAL|POPT_ARGFLAG_OR)
/*!< set arg bit(s) */
#define POPT_BIT_CLR (POPT_ARG_VAL|POPT_ARGFLAG_NAND)
/*!< clear arg bit(s) */
In fact (IIRC), about the only needed change was to add a validation
bit that sez' that opt->argDescrip does indeed contain a recipe
for option value transform parsing (including auto- inccrement/decrement
as trivial sub-cases):
#define POPT_ARGFLAG_CALCULATOR 0x00100000U /*!< argDescr has RPN
string */
While there's many details that I'm not yet happy with using a RPN
caclulator, I'm rather interested in the KISS properties of
parsing a string rather than ornamenting an API/ABI with
all sorts of speshulness that makes POPT too hard to use.
Note that there's enough functionality implemented already
(integer exponentiation is 3 lines) that I can easily
see how to generate 64bit RSA keypairs using the RPN calculator.
I'll likely implement 64bit RSA keypair generation as a testcase
even if there's hardly a usage case.
(aside)
Please also note that most of the existing RPN implementation
was swiped from the BeeCrypto Calcultor, a JavaScript implementation
with MPI's that is most definitely able to generate cryptographic quality RSA
(and ECDSA) keypairs. The limitation of int64_t arithmetic in POPT
might well be removed by making the RPN calculator functionality
in POPT 2.0 "pluggable".
It's the pluggable API and the extensibility that I'm interested in seeing
in POPT 2.0, not a RPN calculator or arithmetic per-se.
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
