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

[Sean Bright]

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


You may want to throw a test of ast_calloc_with_stringfields() in here as well, just for good measure.

- Sean


On 2009-03-04 17:48:02, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/185/
> -----------------------------------------------------------
> 
> (Updated 2009-03-04 17:48:02)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> 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
> -----
> 
>   /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
> 
>