Michael Hunter wrote: > On Wed, 05 Aug 2009 12:10:11 +0100 > Alan Maguire <Alan.Maguire at Sun.COM> wrote: > > >> ...and it'd help if I provided a pointer to the webrev ;-) >> >> http://zhadum.east.sun.com/export/ws/amaguire/nwam1-fixes/webrev/ >> > > door_if.c:155 There should be a log here that we truncated the list. > In the rare event it happens it will be a lot easier to diagnose that > way. > > libnwam_backend.c:358 This should be at the top of the file. > > both accepted. > libnwam_files.c:456-7 objnames is only calloc()d if objname is NULL, > yet you free it without a guard? There are several more examples of > this close by. > not sure I see where this happens - all free()s of objnames seem to have the "if (objname == NULL)" guard. > libnwam_files.c:482 You don't free objnames[i] on error exit eventhough > it contains references to allocated memory. > > good catch, thanks! > libnwam_files.c:528-540 The chunk of code that frees the list and sets > the return value is in several different exit paths. Consider moving > this to the end, setting state variables, and jumping to it. > > done. > libnwam_known_wlan.c:173 This leaks memory if the first allocation > succeeds but the second doesn't. > > fixed. > libnwam_known_wlan.c:182 how do you know num_wlan is not 0? > > we don't call the callback if it is. > libnwam_known_wlan.c:215-221 This chunk of exit code is duplicated. > Consider moving it to a common exit path. > > done. Thanks for the review!
Alan
