Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

crates/stdlib/src/socket.rs (3)

1187-1242: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Do not accept an AF_CAN payload you never serialize.

This branch allows (interface, addr) but only writes can_family and can_ifindex; tuple[1] is ignored. That means bind(), connect(), and sendto() can silently target the wrong CAN endpoint instead of rejecting unsupported tuple shapes.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/stdlib/src/socket.rs` around lines 1187 - 1242, The AF_CAN branch
currently accepts a two-element tuple (interface, addr) but ignores tuple[1];
update this logic to either fully serialize the second element into sockaddr_can
or reject two-element tuples: simplest fix is to disallow tuple.len() == 2 —
change the tuple length validation in the AF_CAN branch (the code that builds
`tuple: PyTupleRef`) to only accept a single-element tuple `(interface,)` and
return a TypeError if a second element is provided; reference the AF_CAN branch,
`tuple`, `can_addr`/`sockaddr_can`, and `caller` when making the change so
callers get a clear error instead of silently ignoring the second element.

---

2279-2289: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

AF_CAN addresses are truncated on the read path.

get_addr_tuple() always returns (ifname,) for AF_CAN, so recvfrom(), getsockname(), and getpeername() lose the CAN-specific address payload. That breaks address round-tripping for protocol-specific CAN sockets.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/stdlib/src/socket.rs` around lines 2279 - 2289, get_addr_tuple()
currently collapses AF_CAN sockaddr_can into only (ifname,) losing the can_id
and breaking round-trips for recvfrom()/getsockname()/getpeername(); fix by
reading both can_ifindex and can_id from the sockaddr_can (use unsafe {
&*(addr.as_ptr() as *const c::sockaddr_can) }), convert ifindex to ifname as
before, and return a tuple containing both fields when can_id != 0 (e.g.
(ifname, can_id)) or include a zero/null can_id explicitly so
vm.ctx.new_tuple(...) produces the full CAN address instead of only
vm.ctx.new_str(ifname).into().

---

1343-1348: ⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Add missing EISCONN constant to the platform abstraction layer.

Line 1347 references c::EISCONN, but this constant is not exported from rustpython_host_env::socket. The import list at lines 60-85 in crates/stdlib/src/socket.rs does not include it, and it's missing from both:

• The Windows WinSock imports (where WSAEISCONN must be added and mapped)
• The Unix libc exports (where EISCONN should be re-exported)

This is a compile blocker on all platforms. Add EISCONN to crates/host_env/src/socket.rs by either directly importing it from libc (Unix) or mapping WSAEISCONN as a platform-specific constant (Windows), then update the mod c re-export list to include it.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/stdlib/src/socket.rs` around lines 1343 - 1348, Add the missing
EISCONN constant to the platform abstraction so c::EISCONN used in socket.rs
compiles: in crates/host_env/src/socket.rs import/re-export EISCONN for Unix
(pull from libc::EISCONN) and on Windows define/map a constant from winsock
(WSAEISCONN) to the same name, then add EISCONN to the mod c re-export list;
this will satisfy the use of c::EISCONN in methods like sock_op /
SelectKind::Connect and ensure platform-specific mapping for WSAEISCONN on
Windows.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

crates/stdlib/src/socket.rs (1)

2319-2323: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Avoid panic on non-UTF8 hostnames in gethostname.

Line 2322 calls err.into_string().unwrap() on an OsString error, which panics for non-UTF8 hostnames. Use vm.fsdecode() instead, which is the idiomatic RustPython pattern for handling OS strings with potential non-UTF8 content and is already used elsewhere in this file (line 2279).

Proposed fix

 #[pyfunction]
 fn gethostname(vm: &VirtualMachine) -> PyResult<PyStrRef> {
-    rustpython_host_env::socket::hostname()
-        .into_string()
-        .map(|hostname| vm.ctx.new_str(hostname))
-        .map_err(|err| vm.new_os_error(err.into_string().unwrap()))
+    let hostname = rustpython_host_env::socket::hostname();
+    Ok(vm.fsdecode(hostname.as_os_str()))
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/stdlib/src/socket.rs` around lines 2319 - 2323, The map_err closure in
the gethostname path currently calls err.into_string().unwrap(), which can panic
on non-UTF8 hostnames; replace that unwrap with the RustPython fsdecode helper
so the OS string is safely converted into a Python string for the error. Locate
the closure on the result of rustpython_host_env::socket::hostname() (the
map_err that constructs vm.new_os_error) and change it to call vm.fsdecode on
the OsString/OsStr error and pass that decoded string into vm.new_os_error (use
vm.fsdecode instead of into_string().unwrap()).