* patrick keshishian <[email protected]> [2012-04-12 00:52]: > On Wed, Apr 11, 2012 at 3:14 PM, Henning Brauer > <[email protected]> wrote: > > * patrick keshishian <[email protected]> [2012-04-11 14:55]: > >> On Wed, Apr 11, 2012 at 12:20:30PM +0200, Henning Brauer wrote: > >> don't you need two different index vars for this next > >> section? > > no, why? > I put the caveat that I am not familiar with the code (and its use). > So apologies if I'm making grave assumptions on the use case (more > below). > > >> > + for (i = 0; i < n; i++) > >> > + if (i < npflogifs) > >> > + p[i] = pflogifs[i]; > >> > + else > >> > + p[i] = NULL; > > > > i think that is pretty clear: each slot in the newly allocated p gets > > the same value as it had in the old pflogifs, once we're at the end of > > pflogifs we set the remaining slots to NULL. unused slots were NULL > > before so just inheriting the NULL is safe. > > Unless pflog_clone_destroy() takes out one in the middle of the list.
what is the problem then? the slot is NULL in pflogofs then and we copy that NULL. all good. > Now, if it is the case that pflog_clone_destroy() won't ever take out > an entry in the middle of pflogifs, then ignore my comments. take out? a slot can be nulled. the index is the interface index, so if just pflog25 exists that array has 26 entries. > OK. So the _destroy() code will always take out entries from the end > of the pflogifs array. no, but your might be confused about the "take out", see above. pflogifs[25] is always pflog25, no matter how many pflog interfaces exist. -- Henning Brauer, [email protected], [email protected] BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
