I applied this patch.<br>Then I remember to run "make check", and it turns out that "make check" fails with a compile error in code used for testing.<br>So I've sent a patch for the compile error.<br>
I also made some stylistic improvements that I've sent as a separate patch.<br><br>However, the failure of "make check" also reminds me that it would be nice to have some tests of the IPv6 address parsing and access control,<br>
analogous to the AccessDenied_Case and ParseMask_Case tests in test/testdistcc.py. If you could make a patch for that, I'd really appreciate it.<br><br>Cheers,<br> Fergus.<br><br><div class="gmail_quote">On Wed, Jul 22, 2009 at 10:32 AM, Fergus Henderson <span dir="ltr"><<a href="mailto:fergus.henderson@gmail.com">fergus.henderson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Looks good to me.<br>
<br>
There are some minor style issues where improvements are possible, e.g. using *iptr++ = ... everywhere instead of mixing the increments of iptr in the for(); and using the same type with just the ipv6 field of the union #ifdef'd, rather than the whole type. But this I'd fine as is.<div>
<div></div><div class="h5"><br>
<br>
On Jul 21, 2009, at 5:15 AM, Bob Ham <rah@bash.sh> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
On Mon, 2009-07-20 at 22:23 -0400, Fergus Henderson wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Oh, I see that the old code that this is replacing didn't check the<br>
return value of strdup() either.<br>
</blockquote>
<br>
Indeed, both of the issues you raised were a continuation of the modus<br>
operandi. As you noted, the return value of strdup() was not checked.<br>
Also, the following non-standard C was used in srvnet.c:<br>
<br>
- const in_addr_t *a4;<br>
...<br>
- a4 = (const in_addr_t *) &a6->s6_addr[12];<br>
<br>
<br>
Regardless, I've updated the patch to correct these issues. I've also<br>
made two more updates. One is a fix to ensure the maximum bit mask size<br>
is set according to the address family and not just whether RFC2553<br>
support is enabled.<br>
<br>
The other, slightly more worrying update modifies the non-RFC2553 code<br>
to use inet_aton() instead of inet_pton(). The inet_pton() function is<br>
defined in RFC2553. This is worrying because it means that people have<br>
been compiling distcc without RFC2553 support enabled but still using a<br>
function defined by that RFC. The fact that this state has continued<br>
without being noticed previously calls into question the value of<br>
maintaining non-RFC2553 code at all.<br>
<br>
<br>
-- <br>
Bob Ham <rah@bash.sh><br>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the "distcc-patches" list.<br>
To post to this list, send email to <<a href="mailto:distcc-patches@googlegroups.com" target="_blank">distcc-patches@googlegroups.com</a>>.<br>
To unsubscribe from this list, send email to <<a href="mailto:distcc-patches-unsubscribe@googlegroups.com" target="_blank">distcc-patches-unsubscribe@googlegroups.com</a>>.<br>
For archives and more options, see <<a href="http://groups.google.com/group/distcc-patches" target="_blank">http://groups.google.com/group/distcc-patches</a>>.<br>
-~----------~----~----~----~------~----~------~--~---<br>
<br></div></div>
<distcc-v6-acl-2.patch><br>
</blockquote>
</blockquote></div><br><br clear="all"><br>-- <br>Fergus Henderson <<a href="mailto:fergus.henderson@gmail.com">fergus.henderson@gmail.com</a>><br>