On Friday, 18 June 2010, at 20:31:28 (-0400),
Jeff Johnson wrote:
> But note run-time, where its not always possible to do the test,
> particularly if popt was built by vendors differently, or different
> versions or feature sets.
>
> What I was envisioning is merely a Bloom filter with an API like
>
> bool poptHasFeature(const char * s)
>
> Then during build the strings/aliases are pumped into a Bloom
> filter, and the resultant bitsset is just stashed into octets
> and fed to (already exists in popt-1.16)
>
> int poptBitsChk(/*...@null@*/poptBits bits, /*...@null@*/const char * s)
> /*...@*/;
>
> It would be quite a simple API, and reasonably general/extensible
> (depending on how the bitset was generated during build) without
> all the usuall "fluff" of tables of arrays of ptrs of ...
>
> ... but since POPT is unlikely to accumulate 32 "features" this century,
> well, it could just be a simple enum of "features" returned as an int32.
Ah, okay. I guess I was envisioning for runtime checks:
void *f = dlopen(NULL, RTLD_LAZY);
if (dlsym(f, "popt_something")) {
...
}
But for cases where that's not possible, either of your ideas is
reasonable.
> Hmmm ... I suspect I'll be lazy and do nothing until I'm forced.
Spoken like a true engineer. ;-)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@kainx.org>
Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"You did not tell the truth, and so you will have to pay the
consequences." -- Bob Barker, "Truth or Consequences"
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
