Re: Review Request 40435: Fixed pointer alignment error in IP::create().

[Gilbert Song]

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

[Michael Park]

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

[Neil Conway]

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

[Neil Conway]

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

[Neil Conway]

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

[Mesos ReviewBot]

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

[Michael Park]

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


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)


We should use `auto` here, since we already specify the type on the right.

```cpp
  const auto* addr = reinterpret_cast(&_storage);
  return create(*addr);
```



3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (lines 241 - 244)


`auto` here as well:

```cpp
  const auto* addr = reinterpret_cast(&_storage);
  return IP(addr->sin_addr);
```



3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (lines 247 - 249)


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

[Neil Conway]

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

[Benjamin Bannier]

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

[Benjamin Bannier]

> On Nov. 18, 2015, 10:57 a.m., Benjamin Bannier wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp, line 233
> > 
> >
> > 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();
> 
> 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().

[Benjamin Bannier]

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


For (local) consistence this whole block should probably be indented by two 
spaces.



3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (line 233)


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



3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (line 237)


Indent this block by two spaces.



3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp (line 240)


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

[Neil Conway]

> On Nov. 18, 2015, 10:57 a.m., Benjamin Bannier wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp, line 233
> > 
> >
> > 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();

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

[Neil Conway]

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

Re: Review Request 40435: Fixed pointer alignment error in IP::create().

[Mesos ReviewBot]

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

[Mesos ReviewBot]

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

Review Request 40435: Fixed pointer alignment error in IP::create().

[Neil Conway]

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