> On Dec. 3, 2015, 4:26 a.m., Michael Park wrote:
> > Could you also create a clean-up patch to get rid of the unnecessary 
> > `struct` disambiguators in this file?

I kinda like leaving "struct" as-is, because we're interfacing with C-style 
APIs where "struct" is syntactically significant -- when reading C code, I 
expect to see "struct sockaddr", not just "sockaddr". What do you think?


- Neil


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


On Dec. 3, 2015, 6:28 a.m., Neil Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40435/
> -----------------------------------------------------------
> 
> (Updated Dec. 3, 2015, 6:28 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Ben Mahler, Joris Van Remoortere, 
> Michael Park, 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 
> 3e506e1e94ee32e3a19870e1fd72d9968c5f8e67 
> 
> 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