> 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); > > Neil Conway wrote: > 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.
Fair enough ;) - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/40435/#review107000 ----------------------------------------------------------- On Nov. 18, 2015, 11:09 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, 11:09 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 > >
