Merged revisions 376820-376821 via svnmerge from
file:///srv/subversion/repos/asterisk/trunk ........ r376820 | pkiefer | 2012-11-29 10:44:42 -0600 (Thu, 29 Nov 2012) | 14 lines Fix chan_sip websocket payload handling Websocket by default doesn't return an ast_str for the payload received. When converting it to an ast_str on chan_sip the last character was being omitted, because ast_str functions expects that the given length includes the trailing 0x00. payload_len only has the actual string length without counting the trailing zero. For most cases this passed unnoticed as most of SIP messages ends with \r\n. (closes issue ASTERISK-20745) Reported by: I?\195?\177aki Baz Castillo Review: https://reviewboard.asterisk.org/r/2219/ ........ r376821 | dlee | 2012-11-29 11:16:50 -0600 (Thu, 29 Nov 2012) | 5 lines Fixed ast_random's comment about locking. The original comment was separated from the code at some point, and didn't reflect the use of libc's other than glibc for Linux. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@376827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
parent
9b9da2938b
commit
93ec26e40a
2 changed files with 8 additions and 4 deletions
|
@ -2635,7 +2635,7 @@ static void sip_websocket_callback(struct ast_websocket *session, struct ast_var
|
||||||
if (opcode == AST_WEBSOCKET_OPCODE_TEXT || opcode == AST_WEBSOCKET_OPCODE_BINARY) {
|
if (opcode == AST_WEBSOCKET_OPCODE_TEXT || opcode == AST_WEBSOCKET_OPCODE_BINARY) {
|
||||||
struct sip_request req = { 0, };
|
struct sip_request req = { 0, };
|
||||||
|
|
||||||
if (!(req.data = ast_str_create(payload_len))) {
|
if (!(req.data = ast_str_create(payload_len + 1))) {
|
||||||
goto end;
|
goto end;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
10
main/utils.c
10
main/utils.c
|
@ -1487,9 +1487,6 @@ int ast_remaining_ms(struct timeval start, int max_ms)
|
||||||
|
|
||||||
#undef ONE_MILLION
|
#undef ONE_MILLION
|
||||||
|
|
||||||
/*! \brief glibc puts a lock inside random(3), so that the results are thread-safe.
|
|
||||||
* BSD libc (and others) do not. */
|
|
||||||
|
|
||||||
#ifndef linux
|
#ifndef linux
|
||||||
AST_MUTEX_DEFINE_STATIC(randomlock);
|
AST_MUTEX_DEFINE_STATIC(randomlock);
|
||||||
#endif
|
#endif
|
||||||
|
@ -1508,6 +1505,13 @@ long int ast_random(void)
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
#endif
|
#endif
|
||||||
|
/* XXX - Thread safety really depends on the libc, not the OS.
|
||||||
|
*
|
||||||
|
* But... popular Linux libc's (uClibc, glibc, eglibc), all have a
|
||||||
|
* somewhat thread safe random(3) (results are random, but not
|
||||||
|
* reproducible). The libc's for other systems (BSD, et al.), not so
|
||||||
|
* much.
|
||||||
|
*/
|
||||||
#ifdef linux
|
#ifdef linux
|
||||||
res = random();
|
res = random();
|
||||||
#else
|
#else
|
||||||
|
|
Loading…
Reference in a new issue