[Asterisk-code-review] vector: Add options for alternate memory management (asterisk[13])

[George Joseph]

Hello Jenkins2, 

I'd like you to reexamine a change. Please visit

    https://gerrit.asterisk.org/10611

to look at the new patch set (#2).

Change subject: vector:  Add options for alternate memory management
......................................................................

vector:  Add options for alternate memory management

The vector implementation has been using the ast_calloc, ast_free,
and ast_malloc functions for memory management but there are
situations where the vector may be used to process error or
backtrace information where an error in the ast_ MM functions
could cause a recursive error situation.

* Added an ast_calloc_ptr function that, regardless of MALLOC_DEBUG,
  always points to a real function and not a macro.

* Added an ast_std_strdup function that always calls the libc strdup
  function regardless of MALLOC_DEBUG.  Will be needed for a
  follow-on commit.

* Added 3 virtual function pointers for calloc, free and element
  cleanup to the vector structures.  AST_VECTOR_INIT defaults these
  to ast_calloc_ptr, ast_free_ptr and NULL respectively.  This
  preserves existing behavior.

* All places in vector.h that had called the ast_ functions
  directly now use the virtual function pointers instead.

* A new macro AST_VECTOR_INIT_MM_FN() allows the caller to specify
  the 3 new functions.  The element cleanup function is optional.

* Two new macros AST_VECTOR_CLEANUP and AST_VECTOR_PTR_CLEANUP will
  use the 3 virtual functions to...
    1. Cleanup all elements in the vector (provided the element
       cleanup function was specified in AST_VECTOR_INIT_MM_FN)
    2. Use the free virtual function to free the internal "elems"
       array.
    3. For AST_VECTOR_PTR_CLEANUP, use the free virtual function to
       free the externally allocated vector structure itself.

* cli.c was using a calloc'd vector without having called
  AST_VECTOR_INIT() which used to be effectively safe but was never
  technically correct.  It now calls AST_VECTOR_INIT.

Example where a function must return a vector that doesn't use the
ast_ memory management functions.  Error checking omitted for
brevity.

struct ast_vector_string *get_somevector()
{
	struct ast_vector_string *strings = ast_std_malloc(sizeof(*strings));
	AST_VECTOR_INIT_MM_FN(strings, 0, ast_std_calloc, ast_std_free,
	   ast_std_free);
	AST_VECTOR_APPEND(strings, ast_std_strdup(somestring1);
	AST_VECTOR_APPEND(strings, ast_std_strdup(somestring2);
	AST_VECTOR_APPEND(strings, ast_std_strdup(somestring3);
	return strings;
}

In this case, the ast_std_calloc function will be used to allocate
the vector's elements array.

void myfunc()
{
	int i;
	struct ast_vector_string *strings = get_somevector();
	for (i = 0; i < AST_VECTOR_SIZE(strings); i++) {
		AST_LOG(LOG_ERROR, "%s\n", AST_VECTOR_GET(strings, i));
	}
	AST_VECTOR_PTR_CLEANUP(strings);
}

Notice that myfunc() doesn't have to worry about how either
the vector itself or the elements were allocated.  It just
calls AST_VECTOR_PTR_CLEANUP() and that macro uses ast_std_free
to free the elements, the internal "elems" array, and the vector
structure itself.

Change-Id: I0d871dfed9ce215fd11aa03e7d6cfaf385b55597
---
M include/asterisk/astmm.h
M include/asterisk/utils.h
M include/asterisk/vector.h
M main/astmm.c
M main/cli.c
5 files changed, 124 insertions(+), 11 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/11/10611/2
-- 
To view, visit https://gerrit.asterisk.org/10611
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I0d871dfed9ce215fd11aa03e7d6cfaf385b55597
Gerrit-Change-Number: 10611
Gerrit-PatchSet: 2
Gerrit-Owner: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Jenkins2 (1000185)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20181109/1354e35b/attachment.html>