src/handler.c: In function 'handler_system_delete_all':
src/handler.c:706:25: warning: 'key2' may be used uninitialized in this function [-Wmaybe-uninitialized]
hash_add(conn->id_handlers, key2, head);
`hash_iter_next()` returns a pointer to an element of the data structure
which is persistent and not altered while calling `hash_iter_next()`.
Therefor we don't have to dup the string, but simply can remember the
pointer.
In the case where the element would be `hash_drop()`'ped which contains
the key, the key is not accessed after it has been free'd.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Const variables in prototypes don't add much value, but make the code
larger and redundant. Remove these const keywords.
Note, this doesn't apply to pointers to const memory.
There are situations when applications need more predictable timed
handlers that don't depend on connection status. Other usecase of
the global handlers is to manage offline connections, for example,
reconnect after a disconnection.
@sjaeckel integrated clang-format with formal coding style. Run his
script and commit changes.
There are pros and cons of this commit.
Mixed coding style is a "broken window". A good single style simplifies
reading and writing code.
On the other hand, this is a big change which will lead to conflicts.
Fixes the next warning:
src/handler.c:683:25: error: ‘key2’ may be used uninitialized in
this function [-Werror=uninitialized]
In fact key2 initialised and used under the same condition.
xmpp_conn_t object can be reused with saving user's handlers.
However, saving system handlers can lead to a fail during connection
process. This is because old object may contain timed handlers for
missed features or other handlers that would handle incoming stanzas
incorrectly.
the C standard says that you're not allowed to cast a function pointer to
something else
6.3.2.3 §8:
A pointer to a function of one type may be converted to a pointer
to a function of another type and back again
User's handler may delete other handlers. If deleted handler is the next
or the previous to the running one it leads to a list corruption.
Don't cache previous/next items when we walk through a handler's list.
According to #97. A single callback can distinguish different cases
using the userdata. Current implementation doesn't allow to delete a
particular couple (handler, userdata), but rather deletes all handlers
regardless of the userdata.
If interface function returns char* the result must be freed with
xmpp_free().
In case of const char* the result must not be changed by user. Also, the
result is valid only during stanza lifetime.
