7bit changes to libosmocore

[Holger Hans Peter Freyther]

Dear LaF0rge, Andreas,

I am really disappointed about the used process for this change. As
an absolute minimum run "make check" after bigger changes. The run
takes about 20 seconds (and that is probably 15s in the timer test),
I have to spend way more time fixing the fall-out from that and it
creates the impression that you do not value my time!

I think Andreas should have posted this kind of change to the mailing
list and ask for review. The way it was done is really unacceptable
and the build is still broken. And to make it worse I think the change
is wrong in several ways:

1.) The issue of the last '7bit' being 'empty' only applies to USSD/CB:

"If the total number of characters to be sent equals (8n-1) where
n=1,2,3 etc. then there are 7 spare bits at the end of the message.
To avoid the situation where the receiving entity confuses 7 binary
zero pad bits as the @ character, the carriage return or <CR> character
(defined in subclause 7.1.1) shall be used for padding in this situation,
just as for Cell Broadcast."

In SMS one has both the octet length and the character length inside
the messages. In USSD this information is not present.


2.) The semantic of the change is bad.

+	octet_len = response_len*7/8;
+	if (response_len*7%8 != 0)
+		octet_len++;
+	/* Warning, response_len indicates the amount of septets
+	 * (characters), we need amount of octets occupied */

Every caller of gsm_7bit_encode now needs to consider adding this change,
it is better to move this into gsm_utils.c. E.g. take a look at my branch
called zecke/features/alpha-numeric for a gsm_7bit_encode_oct. Which
comes with a testcase... and moves this responsibility into libosmocore
and is based on the real octets written (instead of trying to figure it
our afterwards).

We all make money by working on Osmocom sub-projects and I really can't
stand such amateurish work. Can we force reset master to before the merge
and try again?


cheers
	holger