----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/40435/#review107000 -----------------------------------------------------------
3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (line 232) <https://reviews.apache.org/r/40435/#comment165878> For (local) consistence this whole block should probably be indented by two spaces. 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (line 233) <https://reviews.apache.org/r/40435/#comment165885> 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); 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (line 237) <https://reviews.apache.org/r/40435/#comment165887> Indent this block by two spaces. 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (line 240) <https://reviews.apache.org/r/40435/#comment165888> Would it make sense to (locally) specialize `stringify` for `sa_family_t` here for this use case and the one above? LGTM, added minor points nevertheless. - Benjamin Bannier 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 > >
