Free attribute "to" before replacing it in xmpp_stanza_reply().
Free value on insertion error in xmpp_stanza_set_attribute().
Don't copy attributes manually. Use xmpp_stanza_set_attribute() instead.
Default timeout was 1 millisecond and it consumed CPU by running the
loop in xmpp_run(). The CPU usage was unacceptable and thus xmpp_run()
was not used by users. Also user can set the timeout by
xmpp_ctx_set_timeout() now.
Event loop already handles the situation when there is a timed handler
which needs to be run before the timeout is reached. Also system awakes
event loop when data arrives to socket.
The only drawback is when timed handler sends data it will be actually
sent after select(2) returns. But this situation can be handled easily by
adding socket to wfds when xmpp_conn_t contains data in sending queue.
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.
Instead, keep the same handler until connection is disconnected. Stream
is opened 3 times during usual workflow. Deleting/restoring the handler
every time brings more places for possible mistakes.
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
For example, XEP-0115 requires binary digest to be base64-encoded.
Add short function to simplify such a digest computation for a single
buffer. This function doesn't allocate memory. Therefore, it can't
fail and doesn't require strophe context (xmpp_ctx_t).
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.
Fixed a bug which caused resolver to return a wrong target name with a
missed ".". The bug was in the part of message_name_get() where a pointer
is handled.
Added checks for buffer overflow.
Added 2 test cases to check a corner case and error handling.
When xmpp_vsnprintf() received count == 0 it still performs write to the
buffer. This leads to a write outside allocated memory, when
xmpp_stanza_to_text() parses a specific stanza. Because of error in
_render_update() writing exactly buflen+1 with xmpp_snprintf() is counted
as valid operation and next xmpp_snprintf will be performed to a buffer
with zero length. This leads to wrong rendering of 1024-length stanzas
and invalid write for specific larger stanzas:
==22436== Invalid write of size 1
==22436== at 0x4E4B3A1: xmpp_vsnprintf (snprintf.c:709)
==22436== by 0x4E4B479: xmpp_snprintf (snprintf.c:722)
==22436== by 0x4E4C011: _render_stanza_recursive (stanza.c:328)
==22436== by 0x4E4C3B3: _render_stanza_recursive (stanza.c:384)
==22436== by 0x4E4C3B3: _render_stanza_recursive (stanza.c:384)
==22436== by 0x4E4C3B3: _render_stanza_recursive (stanza.c:384)
==22436== by 0x4E4C3B3: _render_stanza_recursive (stanza.c:384)
==22436== by 0x4E4C3B3: _render_stanza_recursive (stanza.c:384)
==22436== by 0x4E4C4E5: xmpp_stanza_to_text (stanza.c:435)
==22436== by 0x4E407A8: _handle_stream_stanza (conn.c:1157)
==22436== by 0x4E4EF2B: _end_element (parser_expat.c:157)
==22436== by 0x571005A: doContent (in /usr/lib64/libexpat.so.1.6.2)
==22436== Address 0x63b95b0 is 0 bytes after a block of size 1,024 alloc'd
==22436== at 0x4C2BFE0: malloc (vg_replace_malloc.c:299)
==22436== by 0x4E41947: _malloc (ctx.c:116)
==22436== by 0x4E41A54: xmpp_alloc (ctx.c:204)
==22436== by 0x4E4C4A3: xmpp_stanza_to_text (stanza.c:428)
==22436== by 0x4E407A8: _handle_stream_stanza (conn.c:1157)
==22436== by 0x4E4EF2B: _end_element (parser_expat.c:157)
==22436== by 0x571005A: doContent (in /usr/lib64/libexpat.so.1.6.2)
==22436== by 0x57109FB: contentProcessor (in ...
==22436== by 0x5712A9F: XML_ParseBuffer (in ...
==22436== by 0x4E4F1E7: parser_feed (parser_expat.c:247)
==22436== by 0x4E42BBC: xmpp_run_once (event.c:284)
==22436== by 0x4E42D62: xmpp_run (event.c:336)
Fix xmpp_vsnprintf() and _render_update() behaviour.
Default opening tag doesn't allow to implement XEP-0174. In this case
client needs to send specific attributes. As solution user passes
attributes that are sent inside opening tag. Previous variant of this
function is renamed to xmpp_conn_open_stream_default().
The way to pass attributes is not the best one, but it's used to conform
existent interface of xmpp_stanza_get_attributes().
Remove "raw" suffix from functions that work with a raw connection.
Previously this was incremented, but not decremented. I've corrected
the code to decrement it. It doesn't appear to be used anywhere, but
it is helpful to implement xmpp_graceful_stop().
