25 Nov
2015
25 Nov
'15
3:58 p.m.
On Tue, Nov 24, 2015 at 09:40:48AM +0100, Jacob Erlbeck wrote:
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
On 19.11.2015 15:34, Neels Hofmeyr wrote:
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 :)
+/*! \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
+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.