RPM Community Forums

Mailing List Message of <popt-devel>

RPN calculator wire-up

From: Jeff Johnson <n3npq@mac.com>
Date: Tue 15 Jun 2010 - 20:02:31 CEST
Message-id: <C89F2C08-0160-4E17-9F19-6954A1A329FF@mac.com>
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

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 */

	                                        /*!< set arg bit(s) */
	                                        /*!< 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. 

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
Received on Tue Jun 15 20:02:57 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.