7bit changes to libosmocore

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