On 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
signature.asc
Description: Digital signature
