> On Nov. 18, 2015, 10:57 a.m., Benjamin Bannier wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp, line 233
> > <https://reviews.apache.org/r/40435/diff/1/?file=1129303#file1129303line233>
> >
> >     You didn't start this, but any `struct` token here is unnecessary noise 
> > since this is C++, not C; this antipattern should probably not be 
> > proliferated further.
> >     
> >     If you wanted you could even write lines like this one here as
> >     
> >         const auto addr = reinterpret_cast<const sockaddr_in*>(&storage);

Re: "struct", interesting point. You could argue that for code that interfaces 
with C, using "struct sockaddr" and similar types has some value because it 
matches the C API declarations more closely. I don't feel strongly either way, 
but since the current code uses "struct sockaddr" (as well as "struct stat" and 
so on), I'm inclined to leave as-is unless/until we end up changing things 
consistently.

Re: "auto", in this case I think being more explicit/redundant is probably 
worth it.


> On Nov. 18, 2015, 10:57 a.m., Benjamin Bannier wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp, line 237
> > <https://reviews.apache.org/r/40435/diff/1/?file=1129303#file1129303line237>
> >
> >     Indent this block by two spaces.

Thanks! Good catch.


> On Nov. 18, 2015, 10:57 a.m., Benjamin Bannier wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp, line 240
> > <https://reviews.apache.org/r/40435/diff/1/?file=1129303#file1129303line240>
> >
> >     Would it make sense to (locally) specialize `stringify` for 
> > `sa_family_t` here for this use case and the one above?

Perhaps? :) Please open a RR for it if you think it's worth doing.


- Neil


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


On Nov. 18, 2015, 9:39 a.m., Neil Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40435/
> -----------------------------------------------------------
> 
> (Updated Nov. 18, 2015, 9:39 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-3939
>     https://issues.apache.org/jira/browse/MESOS-3939
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The previous code took the address of a "struct sockaddr", and then cast the
> resulting pointer to "struct sockaddr_storage *". The alignment requirements 
> for
> "struct sockaddr_storage *" are more strict than for "struct sockaddr *", and
> hence this code produced undefined behavior per ubsan in GCC 5.2.
> 
> Along the way, tweak the code to use reinterpret_cast rather than a C-style
> cast, and not to unnecessarily cast-away constness.
> 
> MESOS-3939.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp 
> 6709f5e7f6233983f389203278a0e42694591230 
> 
> Diff: https://reviews.apache.org/r/40435/diff/
> 
> 
> Testing
> -------
> 
> "make check" on Linux/AMD64 + GCC 5.2 + ubsan; without fix, ubsan reports an 
> error. With fix, ubsan does not report (this) error.
> 
> 
> Thanks,
> 
> Neil Conway
> 
>

Reply via email to