> On Jan. 5, 2015, 5:36 p.m., Dominic Hamon wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp, line 388
> > <https://reviews.apache.org/r/29288/diff/3/?file=803230#file803230line388>
> >
> >     this being public is worrying as it suggests that callsites are 
> > responsible for understanding the difference between address families.

I don't understand this. We need to check the family type only in the Address 
internal methods or in some wrappers(eg: getIP).


- Evelina


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29288/#review66666
-----------------------------------------------------------


On Dec. 30, 2014, 5:51 a.m., Evelina Dumitrescu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29288/
> -----------------------------------------------------------
> 
> (Updated Dec. 30, 2014, 5:51 a.m.)
> 
> 
> Review request for mesos and Dominic Hamon.
> 
> 
> Bugs: MESOS-1919
>     https://issues.apache.org/jira/browse/MESOS-1919
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Created the inner class Address encapsulated inside the IP class.
> The class uses a union with the in_addr and in6_addr fields.
> I considered that the The MasterInfo protobuffers should have both an ipv4 
> and an ipv6 field.
> I intend to use the same Classifiers, addition, removal and update of 
> container filters, but write different encode/decode functions for IPv4/ICMP 
> and IPv6/ICMPv6 because the processing of the protocol headers differ.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
> 80578e2207d5436a4414f56417a0fee06ca9a7e9 
>   3rdparty/libprocess/3rdparty/stout/tests/net_tests.cpp 
> 425132e5d7c3770be4a5a39feea5a2f22179b871 
> 
> Diff: https://reviews.apache.org/r/29288/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Evelina Dumitrescu
> 
>

Reply via email to