broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE

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.

I could try to guess what the ctype_by_chreq[] and reason_by_chreq[] items
should be, but to not get distracted from my current task, and since the values
don't seem to be used by the current master branches yet, I decided to simply
revert the libosmocore commit and leave it up to the original authors to follow
up. (No need to mention that those should be merged to libosmocore and openbsc
"at the same time" to avoid builds failing.)

Thanks and apologies for any inconvenience...

~Neels


commit c3c28528de78fd5d50c3a141c2176c0da5dd7075
Refs: 0.9.0-299-gc3c2852
Author:     Alexander Couzens <lynxis@fe80.eu>
AuthorDate: Tue Nov 29 12:42:05 2016 +0100
Commit:     Harald Welte <laforge@gnumonks.org>
CommitDate: Thu Dec 1 15:26:29 2016 +0000

    gsm0408: add chreq_type for CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE

    For BSC-located pcu the BSC must understand the PDCH chan request.

    Change-Id: Ice44dcaaf798f93af3652a96c567f8e16a6cf784
---
 include/osmocom/gsm/protocol/gsm_04_08.h | 2 ++
 1 file changed, 2 insertions(+)

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.

> From that point of view, the static_assert is highly questionable in
> openbsc.git

I'm glad that we have the assert, otherwise we would be writing past the
array's end without noticing now...

IMHO the way to update the enum is to have all patches on gerrit and collect +2
on them. Once the libosmocore part is merged, the openbsc one shall follow as
soon as possible, unfortunately having to wait for the V+1 first.

We could fix one part of this in general with a kind of LAST_ENTRY enum val in
the sense of

	enum vals {
	  VAL1,
	  VAL2,
	  LAST
	};

	struct s {
	  int arr[LAST];
	};

(where 's' stands for gsm_network)

Then the gsm_network struct size would of course change implicitly, depending
on the .h file from libosmocore.

But then it's still not possible to use the newly added enum values in the
openbsc.git (to extend those other const arrays), so a two-part commit is still
needed for this particular patch. --> move the const arrays to libosmocore?

What did you have in mind?

~N

On Fri, Dec 02, 2016 at 01:43:40PM +0100, Neels Hofmeyr wrote:
> > From that point of view, the static_assert is highly questionable in
> > openbsc.git
> 
> I'm glad that we have the assert, otherwise we would be writing past the
> array's end without noticing now...

I would rather have code that doesn't have such assumptions in the
firstp place, without relying on the fact that an enum of a library
doesn't extend in the future.

I see the assert more as a hack around code with broken assumption.

> What did you have in mind?

I don't have the time right now to study the particular code in
question, sorry.  It will hav to wait for another 10 or 20 other things
on my ever growing stack of todo items :/