[ccan] iniparser almost done, a couple of questions before uploading

[Tim Post]

Hi,

I am almost done with iniparser, I have finished the unit tests:

1..12
ok 1   - iniparser_load()      : loading tests/test.ini
ok 2   - iniparser_getnsec()   : 3 entries in dictionary tests/test.ini
ok 3   - iniparser_getsecname(): last dict entry (3) is foo
ok 4   - iniparser_getsecname(): first dict entry is pizza
ok 5   - iniparser_find_entry(): checking if Foo:shemp exists (yes)
ok 6   - iniparser_getstring() : Wine:Grape = Cabernet Sauvignon
ok 7   - iniparser_set()       : Wine:Grape is now Grape Ape
ok 8   - iniparser_getstring() : Wine:Grape = Grape Ape
ok 9   - iniparser_unset()     : Wine:Grape should be unset if stmp3 is
uninitialized (Yes)
ok 10  - iniparser_getint()    : Pizza:Capres = 3
ok 11  - iniparser_getboolean(): Pizza:Capres = true
ok 12  - iniparser_getdouble() : Wine:Alcohol = 12.5
Splint 3.1.2 --- 10 Mar 2009

Finished checking --- no warnings
Splint 3.1.2 --- 10 Mar 2009

Finished checking --- no warnings

The ccan copy will not use splint, I use it to check for legacy stuff
like sprintf() when I'm dumping strange code into a production tree,
plus to keep myself in check when using -Wno-unused.

I have tests written for all non void functions, is that adequate
coverage? For instance, iniparser_unset() is actually void, but the test
is examining its results (making sure it did its job) via
iniparser_getstring(). The checks for iniparser_freedict() (which
actually frees the dictionary structure) would be up to valgrind? So
though the test says iniparser_unset(), its actually confirmed via
iniparser_getstring(), is that alright?

That leads me to my second question. I have 4 instances of uninitialized
variables that valgrind reports, fixing this involves a bit of
refactoring. The code works, withstands abuse and doesn't leak, can I
just upload what I've done now and refactor later?

For the rest, i.e. examples, I have just copied what exists in ccan.

Incidentally, TAP exposed a few bugs, I don't know what I did without
it. It really makes testing easy. Today I plowed through writing unit
tests for two libraries in just over an hour's time :)

Cheers,
--Tim