On Thu, 06 Aug 2009 16:25:22 +0100 Alan Maguire <Alan.Maguire at Sun.COM> wrote:
> 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. Not sure what I saw in the previous code. Looks good. > > 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! Not a problem! mph > > Alan
