build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- the *_CURRENT macros no longer need the list head pointer argument
- add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89088 | murf | 2007-11-07 14:40:28 -0700 (Wed, 07 Nov 2007) | 1 line
In response to 10578, I just ran 1.4 thru valgrind; some of the config leakage I've already fixed, but it doesn't hurt to double check. I found and fixed leaks in res_jabber, cdr_tds, pbx_ael. Nothing major, tho.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Closes issue #10913, reported by tootai, who graciously granted us access
to his Asterisk server, thanks! Daniel, feel free to reopen the bug in
case you can reproduce this on 1.4.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r84902 | phsultan | 2007-10-07 18:15:39 +0200 (Sun, 07 Oct 2007) | 5 lines
Presence packets from a client who's connected with our Jabber ID are
valid, therefore, those clients must be considered as buddies. The resource
string helps us make the distinction between clients.
Closes issue #10707, reported by yusufmotiwala.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@84918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r84890 | phsultan | 2007-10-07 17:52:44 +0200 (Sun, 07 Oct 2007) | 5 lines
Prevent Asterisk from crashing when receiving a presence packet
without resource from a buddy that is known to have a resource list.
Revert a change I previously made, where Asterisk could point to a
freed memory location.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@84891 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79665 | phsultan | 2007-08-16 11:37:10 +0200 (Thu, 16 Aug 2007) | 21 lines
A fix for two critical problems detected while working with Daniel
McKeehan in issue #10184.
Upon priority change, the resource list is not NULL terminated when
moving an item to the end of the list. This makes Asterisk endlessy
loop whenever it needs to read the list. Jids with different resource and
priority values, like in Gmail's and GoogleTalk's jabber clients put
that problem in evidence.
Upon reception of a 'from' attribute with an empty resource string,
Asterisk crashes when trying to access the found->cap pointer if the
resource list for the given buddy is not empty. This situation is
perfectly valid and must be handled. The Gizmoproject's jabber client
put that problem in evidence.
Also added a few comments in the code as well as a handle for the
capabilities from Gmail's jabber client, which are stored in a caps:c tag
rather than the usual c tag.
Closes issue #10184.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r68028 | oej | 2007-06-07 11:55:13 +0200 (Thu, 07 Jun 2007) | 4 lines
Ok, we found out that this is not about if you have any *active* clients using TLS, but
if you have initialized TLS at all during the lifetime of the module. So if you reload
to disable TLS, it won't help.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@68031 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r68027 | oej | 2007-06-07 11:42:26 +0200 (Thu, 07 Jun 2007) | 8 lines
If you have a jabber client that uses TLS, refuse unload. Bad fix, but will prevent
crashes while we are trying to find a workaround.
Iksemel development seems to have stalled and we might have to stop using the
TCP/TLS connections in that library and use our own, which would scale better
from a poll/select perspective I guess. It would also make it easier to migrate
to OpenSSL and stop Asterisk from depending on both OpenSSL and GnuTLS.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@68029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67993 | oej | 2007-06-07 11:00:44 +0200 (Thu, 07 Jun 2007) | 6 lines
Issue #9738 - Make sure we can unload res_jabber. Patch by phsultan - thanks!
Due to a bug in the iksemel library, this will not work if you are using GTLS
in the connection. That's being investigated. If you figure out a way to handle
that without us having to patch iksemel, let us know in the bug report. Thanks.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@68026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r59363 | russell | 2007-03-29 12:43:52 -0500 (Thu, 29 Mar 2007) | 6 lines
When building a response to a subscription, the "from" must be the full Jabber
ID. This fixes some problems where jabber users are not able to add their
Asterisk account to their user list, since they are unable to get Asterisk
to approve their subscription. (issue #8210, reported by caspy, and verified
by bradtem)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@59364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
