Integers should always be aligned. For some platforms (ARM, SPARC) this
is more important than for others. This changeset ensures that the
string field string lengths are aligned on *all* platforms, not just on
the SPARC for which there was a workaround. It also fixes that the
length integer can be resized to 32 bits without problems if needed.
(closes issue ASTERISK-17310)
Reported by: radael, S Adrian
Reviewed by: Tzafrir Cohen, Terry Wilson
Tested by: S Adrian
Review: https://reviewboard.asterisk.org/r/1549
........
Merged revisions 343157 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 343158 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@343163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_string_field_build_va functions were written to take to separate
va_lists to work around FreeBSD 4 not having va_copy defined.
In the end, we don't support anything using gcc < 3 anyway because we use
va_copy all over the place anyway. This patch just simplifies things by
removing the second va_list function arguments in favor of va_copy.
Review: https://reviewboard.asterisk.org/r/1233/
--This line, and those below, will be ignored--
M include/asterisk/stringfields.h
M main/utils.c
M main/channel.c
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@320946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit adds an API call that can be used to allocate a structure along with this stringfield storage in a single allocation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Under some conditions, the memory allocation for stringfields and ao2 objects would not have supplied valid file/function names for MALLOC_DEBUG tracking, so this commit corrects that.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit modifies the stringfield pool allocator to remember the 'owner' of the stringfield manager the pool is being allocated for, and ensures that pools allocated in the future when fields are populated are owned by that file/function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides a number of optimizations to the stringfields API, focused around saving (not wasting) memory whenever possible. Thanks to Mark Michelson for inspiring this work and coming up with the first two optimizations that are represented here:
Changes:
- Cleanup of some code, fix incorrect doxygen comments
- When a field is emptied or replaced with a new allocation, decrease the amount of 'active' space in the pool it was held in; if that pool reaches zero active space, and is not the current pool, then free it as it is no longer in use
- When allocating a pool, try to allocate a size that will fit in a 'standard' malloc() allocation without wasting space
- When allocating space for a field, store the amount of space in the two bytes immediately preceding the field; this eliminates the need to call strlen() on the field when overwriting it, and more importantly it 'remembers' the amount of space the field has available, even if a shorter string has been stored in it since it was allocated
- Don't automatically double the size of each successive pool allocated; it's wasteful
http://reviewboard.digium.com/r/165/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@185581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176216 | kpfleming | 2009-02-16 15:10:38 -0600 (Mon, 16 Feb 2009) | 3 lines
fix a flaw in the ast_string_field_build() family of API calls; these functions made no attempt to reuse the space already allocated to a field, so every time the field was written it would allocate new space, leading to what appeared to be a memory leak.
........
r176254 | kpfleming | 2009-02-16 15:41:46 -0600 (Mon, 16 Feb 2009) | 3 lines
correct a logic error in the last stringfields commit... don't mark additional space as allocated if the string was built using already-allocated space
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
------------------------------------------------------------------------
r159808 | kpfleming | 2008-11-29 10:58:29 -0600 (Sat, 29 Nov 2008) | 7 lines
update dev-mode compiler flags to match the ones used by default on Ubuntu Intrepid, so all developers will see the same warnings and errors
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
------------------------------------------------------------------------
in addition:
move some format attributes from main/utils.c to the header files they belong in, and fix up references to the relevant functions based on new compiler warnings
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132872 | kpfleming | 2008-07-23 06:52:18 -0500 (Wed, 23 Jul 2008) | 2 lines
minor optimization for stringfields: when a field is being set to a larger value than it currently contains and it happens to be the most recent field allocated from the currentl pool, it is possible to 'grow' it without having to waste the space it is currently using (or potentially even allocate a new pool)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
Also fix a common typo I kept seeing (arguement) in various files.
Closes issue #11222, patch by snuffy (with arguement > argument by me).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
details and examples are in include/asterisk/stringfields.h.
Not applicable to older branches except for 1.4 which will
receive a fix for the routines that free memory pools.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r45408 | kpfleming | 2006-10-17 17:24:10 -0500 (Tue, 17 Oct 2006) | 3 lines
optimize the 'quick response' code a bit more... no more malloc() or memset() for each response
expand stringfields API a bit to allow reusing the stringfield pool on a structure when needed, and remove some unnecessary code when the structure was being freed
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@45409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
const-ify some more APIs
remove 'type' field from ast_channel, in favor of the one in the channel's tech structure
allow string field module users to specify the 'chunk size' for pool allocations
update chan_alsa to be compatible with recent const-ification patches
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@9060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
use multiple memory blocks, instead of realloc(), ensuring that field pointers will never become invalid or change
don't run vs(n)printf twice when doing a field build unless required
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@8697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
convert chan_sip sip_pvt and sip_registry structures to use string fields
add 'const' qualifiers to a few API calls that don't modify their input strings
add an asprintf() wrapper to astmm
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@7797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
