Re: OS X compatibility patches
Julian Graham <[email protected]> Mon, 23 Feb 2015 23:05:28 -0500
| Newsgroups | gmane.network.serveez.devel |
|---|---|
| Message-ID | <CANdC_RDT7U=RLiLNxOEtTfpp+zs1XDXrJEYQTi5_b5Ar+V45og@mail.gmail.com> |
Hey ttn! Happy 2015. On Mon, Feb 23, 2015 at 4:30 PM, Thien-Thi Nguyen <[email protected]> wrote: > I have started to apply these patches. (I've decided to > decouple the copyright assignment tang{o,le} from the technical > maintenance duties. This means you will be added to AUTHORS, > etc, and the copyright assignment will need to be done later, > anyway, but at least we can get a usable release out w/o further > delay.) That's great! I'm flattered to be included in the AUTHORS file. > I will look at it w/ fresh eyes tomorrow, but post this anyway > in hopes that you can provide a cogent analysis (or perhaps a > refutation, or a new improved patch) in the meantime. It took me a moment to remember, but: In the original code, `ifc.ifc_len' is always a multiple of `sizeof (struct ifreq)', and so `n' is incremented in the UPDATE as many times as there are interfaces in the buffer. `ifr' is just a pointer version of `n'. The new code acknowledges that the interface structures in `ifc' may have different lengths, and so `n' and `ifr' need to be incremented by the length of each structure in the buffer, an operation complex enough that I moved it out of the UPDATE part of the `for' loop. Think of it as handling a more general case than the original code. > If we can resolve 0005 and apply 0006 (seems straightforward > enough on quick skim) i think it's not unreasonable to release > 0.2.3 in a few days, perhaps by end of week... Yay! Thanks.