[asterisk-dev] [Code Review] String field test module

[Jeff Peeler]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/185/
-----------------------------------------------------------

(Updated 2010-02-02 16:56:27.447202)


Review request for Asterisk Developers.


Changes
-------

This builds upon Mark's work by converting the code to the new test framework and adds two new tests:
1. Shrinking a string field and partially re-expanding it
2. Setting strings in such a way as to create three separate string field pools and then removing the middle pool.

Perhaps though the most important change is in the init function, which ensures the embedded_pool is set to NULL. Seems reasonable to me since it only gets initialized in ast_calloc_with_stringfields currently. It also fixes the crash I've been experiencing.


Summary
-------

This is a test module for the string fields API designed to help get review 165 merged.

The test consists of four parts.

1. Basic allocation and setting of string fields.
2. Shrinking a string field and re-expanding it.
3. Growing the last allocation in a string field pool.
4. Setting a string to a large value such that a new string field pool must be allocated.

In each part, we make sure that the string field is accurate (has the correct value in it), make sure that the 2 bytes before the string field has the correct capacity for the field, and for tests 2-4, we make sure that the string field is where we expect it to be in memory.

The only thing from review 165 that I can't really test in this module is the ability for a string field pool to be freed when it is no longer in use. Well, I could write code that should test that case, but it's not currently possible to verify whether memory is "free" or not.


Diffs (updated)
-----

  /trunk/main/utils.c 244447 
  /trunk/tests/test_stringfields.c PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/185/diff


Testing
-------

I ran the test module and had no error messages printed at all. The test, as written verifies that the code in review 165 is accurate. Of course, if my test is not actually testing things correctly, then that would be problematic. Once this test is validated, I will give a ship it to review 165 since it passes this test.

In addition to running the test as presented here, I used "memory show summary" with MALLOC_DEBUG enabled and verified that the amount of memory allocated by utils.c was the same before and after the tests.

Also, just being a bit paranoid, I ran this test under valgrind and had no errors reported.


Thanks,

Mark