Switch various conversions from GSM/UCS2 to UTF8 from glib based
implementation over to ell.
This also converts all related g_free calls to l_free calls (though in
the end they are equivalent calls to free)
==29809== Conditional jump or move depends on uninitialised value(s)
==29809== at 0x4E826C: stk_file_iter_next (stkutil.c:212)
==29809== by 0x4E8CF8: parse_dataobj_file_list (stkutil.c:635)
==29809== by 0x4EBA29: parse_dataobj (stkutil.c:2410)
==29809== by 0x4ECFB5: parse_refresh (stkutil.c:2971)
==29809== by 0x4EECA3: parse_command_body (stkutil.c:3826)
==29809== by 0x4EF0DF: stk_command_new_from_pdu (stkutil.c:3948)
==29809== by 0x4D50DA: ofono_stk_proactive_command_handled_notify
(stk.c:2885)
As per the ETSI TS 102 223 section 6.5.4, If the terminal
receives an icon, and either an empty or no alpha identifier/text string
is given by the UICC, than the terminal shall reject the command
with general result "Command data not understood by terminal".
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>
There needs to be a way to distinguish between no alphaid and "empty
data object" because on some occasions they have different meanings. In
the Call Control envelope, no Alpha Identifier means the terminal can
inform the user about the call being modified by SIM while empty data
object means no hint should be given.
We need to look at the Mandatory flag and not at the Minimum flag
when parsing CTLVs. The Minimum flag is important when encoding CTLVs
because CR bit is set according to it.
When parsing the full command fails but Command Details has been parsed,
return a struct stk_command containing this information and the type of
parsing problem found. We need the command details to be able to
even respond to the command.
This patch also makes the parser skip over unknown data objects found
in the BER-TLV, if they don't have Comprehension Required set.