mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Conway" <neil.con...@gmail.com>
Subject Re: Review Request 40435: Fixed pointer alignment error in IP::create().
Date Wed, 18 Nov 2015 11:09:13 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message