You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Neil Conway <ne...@gmail.com> on 2015/11/18 10:39:54 UTC
Review Request 40435: Fixed pointer alignment error in IP::create().
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/
-----------------------------------------------------------
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
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Mesos ReviewBot <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/#review107004
-----------------------------------------------------------
Patch looks great!
Reviews applied: [40435]
Passed command: export OS=ubuntu:14.04;export CONFIGURATION="--verbose";export COMPILER=gcc; ./support/docker_build.sh
- Mesos ReviewBot
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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Neil Conway <ne...@gmail.com>.
> 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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Benjamin Bannier <be...@mesosphere.io>.
> 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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Benjamin Bannier <be...@mesosphere.io>.
-----------------------------------------------------------
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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Neil Conway <ne...@gmail.com>.
> 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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Neil Conway <ne...@gmail.com>.
> 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?
>
> Neil Conway wrote:
> 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?
>
> Michael Park wrote:
> Is your perspective that the definitions of these structs are in C headers and therefore should be used as if we were writing C?
> My perspective is that it may be a C header but it still gets compiled __as__ C++ with a C++ compiler.
> I feel like if we were to agree with your argument, we could carry it all the way to: "it makes more sense for us to keep the C-style cast rather than using C++'s `reinterpret_cast` since we're dealing with C API"?
For situations in which there is a functional difference between C-style code and C++-style code (e.g., reinterpret_cast), I'd vote for doing the best/safest/optimal thing. For things like `struct` naming, since it is just a cosmetic difference, I'd probably lean towards matching what you see in idiomatic code that uses the underlying API -- which is typically `struct sockaddr` and so on, at least in my experience. I don't feel strongly about it though -- happy to send a RR if you'd like.
- 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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Michael Park <mp...@apache.org>.
> 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?
>
> Neil Conway wrote:
> 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?
Is your perspective that the definitions of these structs are in C headers and therefore should be used as if we were writing C?
My perspective is that it may be a C header but it still gets compiled __as__ C++ with a C++ compiler.
I feel like if we were to agree with your argument, we could carry it all the way to: "it makes more sense for us to keep the C-style cast rather than using C++'s `reinterpret_cast` since we're dealing with C API"?
- Michael
-----------------------------------------------------------
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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Michael Park <mp...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/#review108773
-----------------------------------------------------------
Ship it!
Could you also create a clean-up patch to get rid of the unnecessary `struct` disambiguators in this file?
3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (lines 214 - 229)
<https://reviews.apache.org/r/40435/#comment168229>
Great comment!
Could you wrap some of the code segments in there in backquotes?
3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (lines 230 - 233)
<https://reviews.apache.org/r/40435/#comment168230>
We should use `auto` here, since we already specify the type on the right.
```cpp
const auto* addr = reinterpret_cast<const sockaddr*>(&_storage);
return create(*addr);
```
3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (lines 241 - 244)
<https://reviews.apache.org/r/40435/#comment168231>
`auto` here as well:
```cpp
const auto* addr = reinterpret_cast<const sockaddr_in*>(&_storage);
return IP(addr->sin_addr);
```
3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (lines 247 - 249)
<https://reviews.apache.org/r/40435/#comment168232>
Not yours, but this fits in one line.
- Michael Park
On Dec. 3, 2015, 1:45 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, 1:45 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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Gilbert Song <so...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/#review108792
-----------------------------------------------------------
Ship it!
Ship It!
- Gilbert Song
On Dec. 2, 2015, 10:28 p.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40435/
> -----------------------------------------------------------
>
> (Updated Dec. 2, 2015, 10:28 p.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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Neil Conway <ne...@gmail.com>.
-----------------------------------------------------------
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.
Changes
-------
Address mpark's comments.
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 (updated)
-----
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
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Mesos ReviewBot <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/#review108770
-----------------------------------------------------------
Patch looks great!
Reviews applied: [40435]
Passed command: export OS=ubuntu:14.04;export CONFIGURATION="--verbose";export COMPILER=gcc; ./support/docker_build.sh
- Mesos ReviewBot
On Dec. 3, 2015, 1:45 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, 1:45 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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Neil Conway <ne...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/
-----------------------------------------------------------
(Updated Dec. 3, 2015, 1:45 a.m.)
Review request for mesos, Benjamin Bannier, Ben Mahler, Joris Van Remoortere, Michael Park, and Niklas Nielsen.
Changes
-------
Avoid duplicating code, per mpark. Add comment, per joris.
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 (updated)
-----
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
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Mesos ReviewBot <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/#review107013
-----------------------------------------------------------
Patch looks great!
Reviews applied: [40435]
Passed command: export OS=ubuntu:14.04;export CONFIGURATION="--verbose";export COMPILER=gcc; ./support/docker_build.sh
- Mesos ReviewBot
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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Benjamin Bannier <be...@mesosphere.io>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40435/#review107154
-----------------------------------------------------------
Ship it!
- Benjamin Bannier
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
>
>
Re: Review Request 40435: Fixed pointer alignment error in
IP::create().
Posted by Neil Conway <ne...@gmail.com>.
-----------------------------------------------------------
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.
Changes
-------
Address review comments: whitespace.
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 (updated)
-----
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