This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Tue, Nov 24, 2015 at 09:40:48AM +0100, Jacob Erlbeck wrote: > On 19.11.2015 15:34, Neels Hofmeyr wrote: > > +/*! \brief Copy an msgb. > > > > I'd write just "a" here, not "an". I seem to be the English nitpicker > > among us ;) > > I do not agree in this case. "msgb" is read em-es-... thus starting with Ah ok, I see your point. I tend to read "message-bee", starting with a consonant, so I'd have written "a". Keep the "an", then :) > > +int msgb_resize_area(struct msgb *msg, uint8_t *area, > > + size_t old_size, size_t new_size) > > +{ > > + int rc; > > + uint8_t *rest = area + old_size; > > + int rest_len = msg->len - old_size - (area - msg->data); > > + int delta_size = (int)new_size - (int)old_size; > > + > > + if (area < msg->data || rest > msg->tail) > > + MSGB_ABORT(msg, "Sub area is not fully contained in the msg data\n"); > > > check for rest < area in addition. Sounds good. Actually, msgb's len fields are typed as uint16_t, so I think old_size and new_size should be uint16_t arguments...? And then, I think these are also necessary: - assert rest_len >= 0, which ensures a valid old_size, i.e. short for old_size <= (msg->len - (area - msg->data)). - assert new_size <= (0xffff - (area - msg->data)) (so that the resulting len is within uint16_t). It's quite time consuming to figure this out in theory, so maybe we can just merge this and have a "break msgb contest", rewarding an Osmocom mug for every msgb API test case that allows arbitrary memory access ;) ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151125/37698038/attachment.bin>