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

[Colin Helliwell]

> On 26 September 2017 at 17:52 Dan Williams <dcbw at redhat.com> wrote:
> 
> On Tue, 2017-09-26 at 16:15 +0100, Colin Helliwell wrote:
> 
> > > On 26 September 2017 at 16:08 Colin Helliwell <colin.helliwell at ln-s ystems.com> wrote:
> > > 
> > > > On 26 September 2017 at 14:23 Aleksander Morgado <aleksander at alek sander.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#GLi
> > > > b.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())
> 
> Looks like a fairly standard PDU... Is that an incoming message
> received by the device, or one you created with MM to send out?
> 
> Dan

Essentially the former, though I originally sent it (on a different SIM) outta MM. At that stage I wasn't sure how much of the binary I needed to encode myself for mmcli (vs. how much mmcli would do for me).
So the initially-posted example was just a 'DEADBEEF', whereas this one above happens to have a load of other garbage in there.
But: can I/you relate the get_data() to the mmcli output?? If nothing else - and assuming the '/' is the delimeter in the former - then there doesn't seem to be enough bytes being shown?