]> git.ipfire.org Git - thirdparty/asterisk.git/commitdiff
Merged revisions 376820-376821 via svnmerge from
authorAutomerge script <automerge@asterisk.org>
Thu, 29 Nov 2012 17:19:50 +0000 (17:19 +0000)
committerAutomerge script <automerge@asterisk.org>
Thu, 29 Nov 2012 17:19:50 +0000 (17:19 +0000)
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

channels/chan_sip.c
main/utils.c

index 44c8037ba867ad1f1011a098f4e90caf4624b5ca..67c2a1c7cd1f74c8f570af924bc5f815e249c6c4 100644 (file)
@@ -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) {
                        struct sip_request req = { 0, };
 
-                       if (!(req.data = ast_str_create(payload_len))) {
+                       if (!(req.data = ast_str_create(payload_len + 1))) {
                                goto end;
                        }
 
index 1ea8371097942bb0eae9ca61e3be73091e24bd30..24a8326a80a229af690e92c1b926efef11009cc7 100644 (file)
@@ -1487,9 +1487,6 @@ int ast_remaining_ms(struct timeval start, int max_ms)
 
 #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
 AST_MUTEX_DEFINE_STATIC(randomlock);
 #endif
@@ -1508,6 +1505,13 @@ long int ast_random(void)
                }
        }
 #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
        res = random();
 #else