rpmio/set.c array initialization uses ... gcc extension

[Tim Mooney]

Building rpm 5.4.12 on x86_64-pc-solaris2.11 (OpenIndiana oi151a8) using the Oracle Studio 12.3 compiler toolchain.

This issue wouldn't affect compilation with gcc but it does affect any other compiler that doesn't implement the gcc "..." array initialization extension.

gmake[2]: Entering directory `/local/src/RPM/BUILD/rpm-5.4.12/rpmio'
source='set.c' object='set.lo' libtool=yes \
        DEPDIR=.deps depmode=none /bin/sh ../depcomp \
        /bin/sh ../libtool --tag=CC --mode=compile cc -m64 -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../lib -I../rpmdb -I../rpmio -I../misc -I../beecrypt/include -I../beecrypt/include -I../beecrypt -I../beecrypt -I../popt -I../popt -D__FUNCTION__=__func__ -I/local/gnu/include -I/local/include -I/local/include/neon -I/local/include/beecrypt -I/local/openssl/include -DRPM_OS_SOLARIS=021100 -I/local/include/db60 -I/usr/include/pcre -xopenmp -Xa -xc99=all -xO3 -g -mt -KPIC -D__FUNCTION__=__func__ -m64 -I/local/gnu/include -I/local/include -I/local/include/neon -I/local/include/beecrypt -I/local/openssl/include -D_GNU_SOURCE -D_REENTRANT -c -o set.lo set.c
libtool: compile: cc -m64 -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../lib -I../rpmdb -I../rpmio -I../misc -I../beecrypt/include -I../beecrypt/include -I../beecrypt -I../beecrypt -I../popt -I../popt -D__FUNCTION__=__func__ -I/local/gnu/include -I/local/include -I/local/include/neon -I/local/include/beecrypt -I/local/openssl/include -DRPM_OS_SOLARIS=021100 -I/local/include/db60 -I/usr/include/pcre -xopenmp -Xa -xc99=all -xO3 -g -mt -KPIC -D__FUNCTION__=__func__ -m64 -I/local/gnu/include -I/local/include -I/local/include/neon -I/local/include/beecrypt -I/local/openssl/include -D_GNU_SOURCE -D_REENTRANT -c set.c -KPIC -DPIC -o .libs/set.o
"set.c", line 128: syntax error before or at: ...
"set.c", line 454: syntax error before or at: ...
cc: acomp failed for set.c
gmake[2]: *** [set.lo] Error 1
gmake[2]: Leaving directory `/local/src/RPM/BUILD/rpm-5.4.12/rpmio'

In both cases, it's an array that's using ... syntax for initialization, which gcc supports and many other compilers won't. I checked the C11 standard and designated array initialization with ... is not part of the standard.

I could generate the table by hand for the 256 elements in the first array, but the array at line 454 has 65536 elements. I'm open to any suggestions you might have for what the least onerous way to make this portable might be.

[Jeff Johnson (n3npq)]

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.

[Tim Mooney (tim-mooney)]

So I'm taking the recommended approach of ifdef'ing out the code that depends on the gcc-array initializer ( ... ), using

#if __GNUC__

#endif

around any code that uses the ... array-initialization extension. This has resulted in me having to ifdef out quite a bit of code from rpmio/set.c, including

  char_to_num
  decode_base62 (it uses char_to_num)
  word_to_num
  decode_base62_golomb (it uses char_to_num and word_to_num)
  decode_set (it uses decode_base62 and decode_base62_golomb)
  cache_decode_set (it uses decode_set)
  test_set (it uses decode_set)

and, problematically,

  rpmsetCmp (it uses cache_decode_set and decode_set)

That becomes a problem, because rpmds.c from lib/librpm needs rpmsetCmp.

At this point I'm stuck. I'm not certain what could be done to replace the call to rpmsetCmp from rpmds.c