1. This check is used only to prevent potential crashes if a buggy driver
reports invalid values for parents, just in case. It does not affect
algorithm logic in any way. That's why I called it paranoidal. It may be
totally excluded provided that all parent values are in the range [0..n-1].
Maybe I missed something, but I can't see any problems here. Can you see any
problems if suppose there's no such check at all?

2. What is the advantage of calloc? In my opinion malloc(n*m) is equivalent
to calloc(n,m) (not fully though since calloc initializes all bits to zero,
but is this advantage?).

Regards,
          Zakhar Levchenko

On 6/6/08, Yair K. <[EMAIL PROTECTED]> wrote:
>
> On Friday 06 June 2008 20:10:35 Zakhar Levchenko wrote:
> > >
> > >
> > > Hi all,
> >
> > I've prepared an optimized version of my patch with the help from Yair K.
> It
> > should throw away empty groups, but not touch non-empty ones. I've tested
> it
> > on my system and it works fine. Clive should also test it to make sure
> empty
> > groups are removed correctly. And if everything is OK I hope Hannu may
> apply
> > it to hg tree.
> >
> > Regards,
> >           Zakhar Levchenko
> >
>
>
> I suggest moving the (parent >= 0) && (parent < n) check back to the loop.
> Since rec 0 is almost always of type MIXT_DEVROOT, you'll abort the loop
> anyway, and you end up running the check once per loop as is. (Also, if it
> isn't (I don't think there's any such case), you might end up allowing an
> empty group at 0). Also, calloc can be used instead, but I see you didn't go
> for it.
>
> Yours,
>
>         Yair K.
>
> _______________________________________________
> oss-devel mailing list
> oss-devel@mailman.opensound.com
> http://mailman.opensound.com/mailman/listinfo/oss-devel
>
_______________________________________________
oss-devel mailing list
oss-devel@mailman.opensound.com
http://mailman.opensound.com/mailman/listinfo/oss-devel

Reply via email to