[PATCH] libmm-glib,sms: fix get|dup_data() introspection annotations

[Colin Helliwell]

> On 26 September 2017 at 16:08 Colin Helliwell <colin.helliwell at ln-systems.com> wrote:
> 
> > On 26 September 2017 at 14:23 Aleksander Morgado <aleksander at aleksander.es> wrote:
> > 
> > We need to specify explicitly that the return type is an array of
> > 
> > guint8 elements.
> > 
> > ---
> > 
> > Hey Colin,
> > 
> > Could you apply this patch and see if the generated introspection support allows you to use the API? It should work as g_bytes_get_data(), i.e.:
> > https://lazka.github.io/pgi-docs/#GLib-2.0/classes/Bytes.html#GLib.Bytes.get_data
> > 
> > ---
> >  libmm-glib/mm-sms.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libmm-glib/mm-sms.c b/libmm-glib/mm-sms.c
> > index a49deb88..0467b6c1 100644
> > --- a/libmm-glib/mm-sms.c
> > +++ b/libmm-glib/mm-sms.c
> > @@ -131,7 +131,7 @@ mm_sms_dup_text (MMSms *self)
> >  *
> > 
> > *   Gets the message data.
> > *
> > 
> >         *   *   Returns: (transfer none): The message data, or %NULL if it doesn't contain any (e.g. contains text instead).
> > 
> >         *   *   Returns: (transfer none) (array length=data_len) (element-type guint8): The message data, or %NULL if it doesn't contain any (e.g. contains text instead).
> > */
> > const guint8 *
> > mm_sms_get_data (MMSms *self,
> > @@ -158,7 +158,7 @@ mm_sms_get_data (MMSms *self,
> > *
> > 
> > *   Gets the message data.
> > *
> > 
> >         *   *   Returns: (transfer full): The message data, or %NULL if it doesn't contain any (e.g. contains text instead). The returned value should be freed with g_free().
> > 
> >         *   *   Returns: (transfer full) (array length=data_len) (element-type guint8): The message data, or %NULL if it doesn't contain any (e.g. contains text instead). The returned value should be freed with g_free().
> > */
> > guint8 *
> > mm_sms_dup_data (MMSms *self,
> > --
> > 2.14.1
> 
> Thanks Aleksander. I've tried this through a simple python console.
> 
> For a textual message:
> 
> > > > m=rcvd[0]
> > > > print m.get_number(), m.get_timestamp(), '"%s"' % m.get_text()
> > > > +447767999999 170925121806+01 "1217"
> > > > m.get_data()
> > > > ''
> > > > type(m.get_data())
> > > > 
> > > > 
> > > > len(m.get_data())
> > > > 0
> 
> For a 'pdu' message:
> 
> > > > m=rcvd[2]
> > > > print m.get_number(), m.get_timestamp(), '"%s"' % m.get_text()
> > > > +447979999999 170925133914+01 "None"
> > > > m.get_data()
> > > > '\xde\xad\xbe\xef'
> > > > type(m.get_data())
> > > > 
> > > > 
> > > > len(m.get_data())
> > > > 4
> > > > 


I haven't yet explored parsing that response format, but another example follows. Can you sanity-check? At first glance it looks a little odd.


mmcli -m 0 -s 1
SMS '/org/freedesktop/ModemManager1/SMS/1'
  -----------------------------------
  Content    |              number: '+447979116437'
             |                data: '079144872000302311000C914477310412820000AA08506215442DCFE9'
  -----------------------------------
  Properties |            PDU type: 'deliver'
             |               state: 'received'
             |             storage: 'me'
             |                smsc: '+447785016005'
             |           timestamp: '170925124043+01'



>>> m=rcvd[1]
>>> print m.get_number(), m.get_timestamp(), '"%s"' % m.get_text()
+447979999999 170925124043+01 "None"
>>> m.get_data()
'\x07\x91D\x87 \x000#\x11\x00\x0c\x91Dw1\x04\x12\x82\x00\x00\xaa\x08Pb\x15D-\xcf\xe9'
>>> type(m.get_data())
<type 'str'>
>>> len(m.get_data())
29