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

> Hmmm ... I suspect I'll be lazy and do nothing until I'm forced.

Spoken like a true engineer.  ;-)


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

Reply via email to