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/12/03 02:45:52 UTC

Re: 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/
-----------------------------------------------------------

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