From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [RFC_PATCH 2/4] smsutil: Editorial changes to sms status report function
Date: Wed, 18 Aug 2010 13:09:01 -0500 [thread overview]
Message-ID: <4C6C21BD.90709@gmail.com> (raw)
In-Reply-To: <201008182040.47764.petteri.tikander@ixonos.com>
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
Hi Petteri,
<snip>
>>> + node->expiration = segment_stat.st_mtime;
>>> + memcpy(node->mrs, buf, sizeof(node->mrs));
>>> + memcpy(&node->total_mrs, buf + sizeof(node->mrs),
>>> + sizeof(node->total_mrs));
>>> + memcpy(&node->sent_mrs,
>>> + buf + sizeof(node->mrs) + sizeof(node->total_mrs),
>>> + sizeof(node->sent_mrs));
>>> +
>>> + memcpy(&node->deliverable, buf + sizeof(node->mrs) +
>>> + sizeof(node->total_mrs) + sizeof(node->sent_mrs),
>>> + sizeof(node->deliverable));
>>
>> To make our lives easier, I'd make the id_table_node structure packed
>> and read the data directly into it. We don't have to worry about
>> byte-ordering at this point.
>>
>
> Yep. So, we'll get rid of memcopies, and temp-buffer allocation. So I'll change
> to this:
>
> struct id_table_node {
> struct sms_address to; // => this will be removed
> unsigned int mrs[8];
> time_t expiration;
> unsigned char total_mrs;
> unsigned char sent_mrs;
> gboolean deliverable;
> } __attribute__((packed));
>
Yes, this seems just fine to me. I already removed the to member by the
way. :)
<snip>
>>> +static gboolean sr_assembly_add_fragment_backup(const char *imsi,
>>> + const struct id_table_node *node,
>>> + unsigned int msg_id)
>>> +{
>>> + int len = sizeof(node->mrs) + sizeof(node->total_mrs) +
>>> + sizeof(node->sent_mrs) + sizeof(node->deliverable);
>>> + unsigned char buf[len];
>>> +
>>> + if (!imsi)
>>> + return FALSE;
>>> +
>>> + memcpy(buf, node->mrs, sizeof(node->mrs));
>>> +
>>> + memcpy(buf + sizeof(node->mrs), &node->total_mrs,
>>> + sizeof(node->total_mrs));
>>> +
>>> + memcpy(buf + sizeof(node->mrs) + sizeof(node->total_mrs),
>>> + &node->sent_mrs, sizeof(node->sent_mrs));
>>> +
>>> + memcpy(buf + sizeof(node->mrs) + sizeof(node->total_mrs) +
>>> + sizeof(node->sent_mrs), &node->deliverable,
>>> sizeof(node->deliverable)); +
>>
>> Again, simply writing the id_table_node structure might be easier here,
>> especially since you're not taking care of loading the expiration member.
>>
>
> Good point:) I forgot this expiration-time member :(
> With packed-node type shouldn't be missed anymore.
>
> I have to bother you little bit more with status report-expiration logic soon,
> because it's not implemented yet..
Sure :)
We might also need to revisit the address / mr matching. Some networks
are stupid and rewrite the SMS address in the status report. E.g. when
I send an SMS to 555-123-4567, the status report comes back with the
address rewritten to +15551234567.
So we might need to allow some fuzzy matching based on the last n digits
or something more clever.
Regards,
-Denis
prev parent reply other threads:[~2010-08-18 18:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1281942533-9126-1-git-send-email-petteri.tikander@ixonos.com>
2010-08-16 7:08 ` [RFC_PATCH 2/4] smsutil: Editorial changes to sms status report function Petteri Tikander
2010-08-16 7:08 ` [RFC_PATCH 3/4] smsutil:add proper checking of sms-address in status report-function Petteri Tikander
2010-08-16 7:08 ` [RFC_PATCH 4/4] smsutil: added function for data handling of status report Petteri Tikander
2010-08-17 19:07 ` Denis Kenzior
2010-08-18 17:53 ` Petteri Tikander
2010-08-18 18:11 ` Denis Kenzior
2010-08-17 18:16 ` [RFC_PATCH 3/4] smsutil:add proper checking of sms-address in status report-function Denis Kenzior
2010-08-17 18:10 ` [RFC_PATCH 2/4] smsutil: Editorial changes to sms status report function Denis Kenzior
2010-08-18 17:40 ` Petteri Tikander
2010-08-18 18:09 ` Denis Kenzior [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C6C21BD.90709@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox