This likely has no effect, but just make sure the regex stops
grabbing message content when it hits the CF/LF that terminates
the message content in text mode.
This method will try to convert the input string to UTF-8. The input string is
supposed to be in the given charset; or otherwise is supposed to be the hex
representation of the string in the given charset.
The introspection data specified the Send() method to return
an array of unsigned integers, presumably the indexes of the
messages just sent. But the code wasn't doing that, leading
to a crash when dbus-glib tried to interpret garbage on the
return.
The problem is that sms_send_auth_cb() gave async_call_done()
as the callback for sending the SMS, but that method just calls
dbus_g_method_return() with no return arguments. dbus-glib
interprets the arguments of dbus_g_method_return() according
to the XML introspection data, and thus it was attempting to
read the non-existent argument as an 'au' and getting garbage.
Fix that by actually returning an array of message indexes from
the SMS send code, and propagate that back to the SMS dbus
code so it can return something sensible.
The first byte of the PDU is the SMSC length, but it's not
the padded SMSC length. So we need to subtract the actual
byte index of the start of the message from length of the
PDU, and since the PDU creation function knows all about
where the SMSC address stops and the message begins, just
have it return that length instead of making the callers
calculate it.
Tests that the last septet (packed in an octet by itself)
doesn't get left off the message like the old code used to
do before "core: fix some bugs in GSM7 packing code".
The existing gsm_pack() had a bug where if the last
septet should be in an octet by itself, that last
octet wouldn't be added. Plus, kinda pointless to
use a GByteArray here when we already know what the
length will be through simple arithmetic.
We can also simplify the function too.
Furthermore, there weren't any testcases for starting
packing at an offset other than zero, so add one.
There's no encoding information about 8-bit SMS messages,
and they are often binary things like ringtones or voicemail
indicator commands. Since there's no point to our parsing
them just let clients deal with it.
Various bits of the code didn't check if response was valid
or not during error conditions, and when an error occurs
sometimes it'll be NULL (since not all errors are translated
errors from the modem, some are serial or general ones). We
have to make sure we don't try to use response->str when
response doesn't exist.
Found in the generic CDMA code likely as a result of
d5d9eec2b5 but was a bug long
before that commit happened anyway.
Change the error handling to be a bit more like what appears to have
been intended: if constructing the regex fails, report an error and
return. The existing code looked like it was set up to do this, but
wasn't quite wired together, and had process-terminating calls
(g_error()) followed by other code.
Change-Id: I4a7cee8fe01291976edc2e343fcbeb73e882f20b
First, arrange for received/complete signals to be sent by calling
cmti_received_has_sms() with the message properties even if the
message isn't complete yet.
Second, make the operation of the List command's multipart message
handling independent of message order by doing one pass to insert the
messages into the cache and second pass to retrieve the complete messages.
Change-Id: I3dcae940d71aec3ddb65c508675f710d1567b0e2
