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/.
Holger Hans Peter Freyther holger at freyther.deOn Mon, Dec 02, 2013 at 10:21:58AM +0100, Jacob Erlbeck wrote: > >> + /* Ensure that the msg->l2h is NULL terminated. */ > >> + if (msgb_tailroom(msg) > 0) > >> + *msg->tail = '\0'; > >> + else if (*(msg->tail-1) == '\r' || *(msg->tail-1) == '\n') > >> + *(msg->tail - 1) = '\0'; > >> + else { > >> + return NULL; > >> + } > > > > The check misses if "tail - 1" is already \0 > Yes, but does this hurt? I wouldn't expect l2 to end with a \0 since the > protocol is defined without one (see below). And even if there was one, > a second one wouldn't be a problem. tailroom == 0 AND msg->l2h[msgb_length(msg) - 1] == '\0' is rejected by your above code. > You mean that tail == (uint8_t *)1 ??? This mustn't happen anyway. true. I had tail not being initialized in mind. But that can not happen. > I don't agree that the caller has to NUL-terminate. It is an > implementation detail of mgcp_handle_message() that it uses string > parsing functions that depend on a terminating \0 character. The Fair enough. I just noticed that the check above is a bit of code and I think it missed one case, so a OSMO_ASSERT is easier to get right. > What's about changing msgb to always write a \0 after the data area > every time tail gets modified? Like with QByteArray you could always > safely use string functions without handling this explicitely. But I'm > afraid there is some code already that relies of changing tail freely > without expecting this to cause this kind of side effect even when used > with put. Perhaps one can make this optional? In theory we always over allocate the msgb and due the usage of talloc_zero should make sure that we have many NULLs at the end. If we want to implement the extra reservation we have a bit of a problem. We generally use a power of two for the allocation (in the hope we get a full page). So if we do: +1: We certainly need to allocate more than a page -1: We might not have enough data. For now. Please change the check to use l2h, msgb_length and handle a NULL terminated input with no tailroom. kind regards holger