Port [c1c9e312a1ec0d7748a58668e6184ae979070752] fix to PDUAddress handling

[daniel]

PDU Address handling also suffers from the problem that the padding will be incorrectly decoded as a character (usually all zeros -> @) if the address is alphanumeric and 7 characters (rather n*8-1) long.

[jluebbe]

3GPP TS 23.038 version 8.2.0 Release 8 has some text about this:

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 clause 6.1.1) shall be used for padding in this situation, just as for Cell Broadcast. If <CR> is intended to be the last character and the message (including the wanted <CR>) ends on an octet boundary, then another <CR> must be added together with a padding bit 0. The receiving entity will perform the carriage return function twice, but this will not result in misoperation as the definition of <CR> in clause 6.1.1 is identical to the definition of <CR><CR>. The receiving entity shall remove the final <CR> character where the message ends on an octet boundary with <CR> as the last character.

This doesn't apply directly to SMS but indicates some special handling might be needed.

[daniel]

This is fixed now in [af530a040b84a62c2d37cb47fa1fde6b66ef9c91].