broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE

[Harald Welte]

On Fri, Dec 02, 2016 at 02:29:34AM +0100, Neels Hofmeyr wrote:
> Heads up, the current openbsc build is broken, as verified by
> https://jenkins.osmocom.org/jenkins/job/OpenBSC/
> 
> This is due to below libosmocore commit, which adds two items to enum
> chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking
> the static assert for gsm_network->ctype_by_chreq's size:
> 
> ../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ‘dummyassert_size’ is negative
>  osmo_static_assert(sizeof(ctype_by_chreq) ==
>  ^
> 
> What this patch lacks is
> 
> * adjustment of ctype_by_chreq[] according to the new additions in
>   libbsc/gsm_04_08_utils.c
> * same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c
> * enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h.

there are related changes in not-yet-pushed commits in openbsc.git,
which should be pushed by the team working on this.

It's really sad that we have such a chicken-and-egg situation now, where
we will introduce a backward-incompatibility, i.e. a newer libosmocore
will be source-code incompatible with older openbsc.  This is really sad
and we should avoid such situations if possible at all.

>From that point of view, the static_assert is highly questionable in
openbsc.git, because it assumes that an enum is never getting extended
in the library :(  But of course we cannot change past versions of
openbsc.git.

But please let's all try to remember this issue and not create one
again.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)