scan-build from clang-9 has reported following:
libubox/list.h:141:2: warning: Use of memory after it is freed
_list_add(_new, head, head->next);
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This dereference could possibly happen if the calloc call fails as the
return value is unchecked. While at it refactor the code little bit to
make it easier to follow, use safe list iterator and provide return
value for ubusd_monitor_connect.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Should save a few cycles, since the data that's
being changed is only the seq number.
And the `ub` is always created as shared.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This makes it clear that `ubus_msg_send()` is only
about sending and queue-ing messages, and has nothing
to do with free-ing.
It can be a bit misleading/confusing when trying to go
through the code and make assumptions about whether a
buffer is free'd in ubus_send_msg(), or is free'd outside.
In `ubusd_proto_receive_message()` the `ubus_msg_free()`
is now called before the `if (ret == -1)` check.
That way, all callbacks will have their messages free'd,
which is what's desired, but confusing, because:
* ubusd_handle_invoke() called ubus_msg_free() before returning -1
* ubusd_handle_notify() called ubus_msg_free() before returning -1
* ubusd_handle_response() called ubus_msg_send(,,free=true) before returning -1
* ubus_msg_send() would call ubus_msg_send(,,free=false)
* all other callback callers would `ubus_msg_send(,,free=true)`
(free the buffers in ubus_msg_send() )
In all other places, where `ubus_msg_send(,,free=true)`
an explicit `ubus_msg_free()` was added.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
