The sockaddr_in is missing documentation of the `sin_len` field.

[jweinst1]

The following code

use libc::{socket, bind, accept, listen, connect, close};
use libc::{sockaddr_in, sockaddr, in_addr};
use libc::{AF_INET, SOCK_STREAM, INADDR_ANY};
use std::os::fd::RawFd;


fn main() {
    unsafe {
        let sock:RawFd = socket(AF_INET, SOCK_STREAM, 0);
        let servaddr = sockaddr_in{sin_zero:[0;8],
                                   sin_family:AF_INET as u8, 
                                   sin_port:u16::from_le_bytes((12001 as u16).to_ne_bytes()), 
                                   sin_addr:in_addr{s_addr:INADDR_ANY}
                               };
        close(sock);
    }
}

Fails to compile with

error[E0063]: missing field `sin_len` in initializer of `sockaddr_in`
  --> src/main.rs:10:24
   |
10 |         let servaddr = sockaddr_in{sin_zero:[0;8],
   |                        ^^^^^^^^^^^ missing `sin_len`

For more information about this error, try `rustc --explain E0063`.
warning: `hello_world` (bin "hello_world") generated 2 warnings
error: could not compile `hello_world` (bin "hello_world") due to previous error; 2 warnings emitted

In https://docs.rs/libc/latest/libc/struct.sockaddr_in.html , there is no documentation of the sin_len field of the struct.

Also i have never heard of this field in C types themselves for sockaddr_in , https://man7.org/linux/man-pages/man3/sockaddr.3type.html so unclear what this field is or does.

[devnexen]

Some oses do have it (e.g. BSD based systems) some don't like Linux/Android indeed. Might have something to do with your build settings.

[devnexen]

with your code snippet on my linux machine it builds ok

cargo build
   Compiling sockin v0.1.0 (/tmp/sockin)
warning: unused imports: accept, bind, connect, listen
 --> src/main.rs:1:20
  |
1 | use libc::{socket, bind, accept, listen, connect, close};
  |                    ^^^^  ^^^^^^  ^^^^^^  ^^^^^^^
  |
  = note: #[warn(unused_imports)] on by default

warning: unused import: sockaddr
 --> src/main.rs:2:25
  |
2 | use libc::{sockaddr_in, sockaddr, in_addr};
  |                         ^^^^^^^^

warning: unused variable: servaddr
  --> src/main.rs:10:13
   |
10 |         let servaddr = sockaddr_in{sin_zero:[0;8],
   |             ^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_servaddr`
   |
   = note: `#[warn(unused_variables)]` on by default

warning: `sockin` (bin "sockin") generated 3 warnings (run `cargo fix --bin "sockin"` to apply 3 suggestions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s

however

cargo build --target x86_64-unknown-freebsd
   Compiling sockin v0.1.0 (/tmp/sockin)
warning: unused imports: `accept`, `bind`, `connect`, `listen`
 --> src/main.rs:1:20
  |
1 | use libc::{socket, bind, accept, listen, connect, close};
  |                    ^^^^  ^^^^^^  ^^^^^^  ^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused import: `sockaddr`
 --> src/main.rs:2:25
  |
2 | use libc::{sockaddr_in, sockaddr, in_addr};
  |                         ^^^^^^^^

error[E0063]: missing field `sin_len` in initializer of `sockaddr_in`
  --> src/main.rs:10:24
   |
10 |         let servaddr = sockaddr_in{sin_zero:[0;8],
   |                        ^^^^^^^^^^^ missing `sin_len`

For more information about this error, try `rustc --explain E0063`.
warning: `sockin` (bin "sockin") generated 2 warnings
error: could not compile `sockin` (bin "sockin") due to previous error; 2 warnings emitted

[JohnTitor]

@jweinst1 We would like to know your target to add the declaration. Note also that the libc crate just exposes a wrapper, which means referencing the man page (or similar) is enough in general (adding these links to each item would be awesome, but it'd be hard work and should be automated... ).

[jweinst1]

My target is as follows

 rustc --version --verbose
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: aarch64-apple-darwin
release: 1.70.0
LLVM version: 16.0.2

[devnexen]

apple shares a lot of userland pieces with freebsd here its definition :