Comment 1 for bug 1219067

Yep the "portability" issues in set.c are well known.

I'm waiting for a usage case (I know what my usage case is) to appear
before attempting some rather straightforward fixes with one-shot
initialization for tables that are 65K in size. There is a run-time approach
(using a variable) and there is a build time approach including a
large table generated by a helper.

Meanwhile the rpmio/set.c code is largely just sketched in atm (and
tested against ALT linux while installing: no build time support has been
attempted yet, it isn't hard but is seriously different).

Ultimately I'd like to see rpmio/set.c have an API that was interchangeable
with rpmio/rpmbf.c (Bloom filters) so that either the set.c or the Bloom filter
could be switched seamlessly: there are many usage cases in RPM for algorithms
that can compute subset booleans efficiently, and set.c does not have
false positive probabilities as Bloom filters do (but set.c is likelier more costly
in both memory/cpu than Bloom filters are).

The easy fix is of course to ignore set.c and add some #ifdef that hides
all the problematic code on OpenSolaris. That is a perfectly acceptable
WORKSFORME patch considering the lack of any usage case for set.c
dependencies outside of ALT Linux.