Yank all `0.3` versions older than `0.3.16`

[faern]

Due to #120. If the standard library ever do change the memory layout of SocketAddr, usage of this crate of versions before 0.3.16 will have undefined behaviour and lead to segfaults. And even if the standard library never do change the layout of those types, those older versions of this crate still makes assumptions they should not.

This is exactly what yanking is for. Marking a release as "should not be used". I think all versions of socket2 from 0.3.0 through 0.3.15 should be yanked from crates.io.

Related issues on other crates having the same problem: deprecrated/net2-rs#107, tokio-rs/mio#1412

[Thomasdezeeuw]

Done: https://crates.io/crates/socket2/versions. I'm leaving v0.1.0 and v0.2.0 although they might have the same problem (I haven't checked), but those aren't maintained any more.

[BWStearns]

Sorry for the necromancy, but if I have a project that uses this 0.3.11 through several dependencies that are all dead, do you have any suggestions for just getting it to compile? I've tried switching the rust versions back to 1.4x.0 (around the time of this original issue) but it doesn't seem to help. Getting it to compile at least would let me migrate to newer versions of the dependencies a bit easier.

    |
156 |         mem::transmute::<SocketAddrV4, sockaddr_in>(v4);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: source type: `SocketAddrV4` (48 bits)
    = note: target type: `sockaddr_in` (128 bits)

[faern]

What happens if you try cargo update -p socket2? That should update socket2 to 0.3.19 unless whatever crate depends on it has pinned a specific version.

What crate has the code you quote the error from? That code is invalid since those two types (no longer) have the same memory layout.

If you use socket2 0.3.11 I'm pretty sure your dependency tree should be able to handle version 0.3.16 and up where this issue is fixed.

[Thomasdezeeuw]

@faern is entirely correct. v0.3.16 fixes this issue and is compatible with v0.3.x, while v0.4.x is not, so we don't want to yank that version.

[BWStearns]

What happens if you try cargo update -p socket2? That should update socket2 to 0.3.19 unless whatever crate depends on it has pinned a specific version.

It bumped it to 0.3.19, That gets me to a very different looking error! Thank you!

warning: `flight-analysis-service` (lib) generated 12 warnings (run `cargo fix --lib -p flight-analysis-service` to apply 8 suggestions)
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/Users/brianstearns/.rustup/toolchains/stable-aarch64-ap ..... <giant path dump omitted>

          ld: warning: pointer not aligned at _grpc_lb_v1_ClientStats_fields+0xB from /Users/brianstearns/rust/wtf/rs-flight-analysis-service/target/debug/deps/libgrpcio_sys-c6e4fac3b43a752f.rlib[344](load_balancer.pb.c.o)
          ld: warning: pointer not aligned at _grpc_lb_v1_ClientStats_fields+0x6A from /Users/brianstearns/rust/wtf/rs-flight-analysis-service/target/debug/deps/libgrpcio_sys-c6e4fac3b43a752f.rlib[344](load_balancer.pb.c.o)
          ld: warning: pointer not aligned at _grpc_lb_v1_LoadBalanceRequest_fields+0x1E from /Users/brianstearns/rust/wtf/rs-flight-analysis-service/target/debug/deps/libgrpcio_sys-c6e4fac3b43a752f.rlib[344](load_balancer.pb.c.o)
          ld: warning: pointer not aligned at _grpc_lb_v1_InitialLoadBalanceResponse_fields+0x1E from /Users/brianstearns/rust/wtf/rs-flight-analysis-service/target/debug/deps/libgrpcio_sys-c6e4fac3b43a752f.rlib[344](load_balancer.pb.c.o)
          ld: warning: pointer not aligned at _grpc_lb_v1_ServerList_fields+0xB from /Users/brianstearns/rust/wtf/rs-flight-analysis-service/target/debug/deps/libgrpcio_sys-c6e4fac3b43a752f.rlib[344](load_balancer.pb.c.o)
          ld: warning: pointer not aligned at _grpc_lb_v1_LoadBalanceResponse_fields+0x1E from /Users/brianstearns/rust/wtf/rs-flight-analysis-service/target/debug/deps/libgrpcio_sys-c6e4fac3b43a752f.rlib[344](load_balancer.pb.c.o)
          ld: pointer not 4-byte aligned at __DATA_CONST+0x81D13, fix alignment or disable chained fixups
          final section layout:
              __PAGEZERO           addr=0x00000000, size=0x100000000, fileOffset=0x00000000
              __TEXT               addr=0x100000000, size=0x00d4c000, fileOffset=0x00000000
                  __text           addr=0x100000920, size=0x0095e82c, fileOffset=0x00000920
                  __stubs          addr=0x10095f14c, size=0x00002190, fileOffset=0x0095f14c
                  __init_offsets   addr=0x1009612dc, size=0x00000084, fileOffset=0x009612dc
                  __const          addr=0x100961360, size=0x00158bc8, fileOffset=0x00961360
                  __gcc_except_tab addr=0x100ab9f28, size=0x0004c510, fileOffset=0x00ab9f28
                  __cstring        addr=0x100b06438, size=0x00016854, fileOffset=0x00b06438
                  __unwind_info    addr=0x100b1cc8c, size=0x0005b980, fileOffset=0x00b1cc8c
                  __eh_frame       addr=0x100b78610, size=0x001d39e8, fileOffset=0x00b78610
              __DATA_CONST         addr=0x100d4c000, size=0x00094000, fileOffset=0x00d4c000
                  __got            addr=0x100d4c000, size=0x000016d0, fileOffset=0x00d4c000
                  __const          addr=0x100d4d6d0, size=0x00091df0, fileOffset=0x00d4d6d0
              __DATA               addr=0x100de0000, size=0x0001c000, fileOffset=0x00de0000
                  __data           addr=0x100de0000, size=0x000030d8, fileOffset=0x00de0000
                  __thread_vars    addr=0x100de30d8, size=0x00000330, fileOffset=0x00de30d8
                  __thread_data    addr=0x100de3410, size=0x00000040, fileOffset=0x00de3410
                  __thread_bss     addr=0x100de3450, size=0x00000518, fileOffset=0x00de3450
                  __bss            addr=0x100de3980, size=0x00015028, fileOffset=0x00000000
                  __common         addr=0x100df89a8, size=0x000005a0, fileOffset=0x00000000
              __LINKEDIT           addr=0x100dfc000, size=0x00a48000, fileOffset=0x00de4000
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

What crate has the code you quote the error from? That code is invalid since those two types (no longer) have the same memory layout.

I'm pretty sure this is mostly coming from the hyper crate or trust-dns-proto.

If you use socket2 0.3.11 I'm pretty sure your dependency tree should be able to handle version 0.3.16 and up where this issue is fixed.

socket2 0.3.11 is required via hyper (0.13.8), ipconfig (0.2.1), and trust-dns-proto (0.8.0).

[BWStearns]

For anyone in the future who runs across this thread (also possible future me): to fix this new second issue right above this, the trick might be to set export MACOSX_DEPLOYMENT_TARGET=11.

@faern thank you so much! I had tried manually editing the versions up earlier but I must have missed something.