Fix socket.getaddrinfo and upgrade socket to 3.13.11#6564
Conversation
📝 WalkthroughWalkthroughThis pull request extends socket functionality by adding Windows WinSock API support, introducing Linux AF_CAN and AF_ALG address family handling, and implementing new socket methods including Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Sorry, something went wrong.
1b3b15b to
02ae8cc
Compare
December 28, 2025 13:35
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
crates/stdlib/src/socket.rs (2)
146-220: Consider consolidating the cfg attributes.The repeated
#[cfg(target_os = "linux")]on each constant is verbose. Consider grouping them under a single cfg block for maintainability:#[cfg(target_os = "linux")] mod can_bcm_constants { pub const CAN_BCM_TX_SETUP: i32 = 1; // ... } #[cfg(target_os = "linux")] #[pyattr] use can_bcm_constants::*;However, if the current style matches the rest of the codebase or is required by the
pyattrmacro, this is fine as-is.
1891-1906: Potential UB: casting const pointer to mut formsg_iov.Line 1901 casts
iovecs.as_ptr()(const pointer) to*mut _formsg_iov. While this pattern is common and the kernel won't actually mutate the buffers forsendmsg, it's technically undefined behavior in Rust to cast away constness if the memory is accessed.Consider using
as_mut_ptr()with a mutable binding:🔎 Suggested fix
- let iovecs: Vec<libc::iovec> = buffers + let mut iovecs: Vec<libc::iovec> = buffers .iter() .map(|buf| libc::iovec { iov_base: buf.as_ptr() as *mut _, iov_len: buf.len(), }) .collect(); // Set up msghdr let mut msghdr: libc::msghdr = unsafe { std::mem::zeroed() }; - msghdr.msg_iov = iovecs.as_ptr() as *mut _; + msghdr.msg_iov = iovecs.as_mut_ptr();
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
Lib/socket.pyis excluded by!Lib/**Lib/test/test_socket.pyis excluded by!Lib/**
📒 Files selected for processing (1)
crates/stdlib/src/socket.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.rs: Follow the default rustfmt code style by runningcargo fmtto format Rust code
Always run clippy to lint code (cargo clippy) before completing tasks and fix any warnings or lints introduced by changes
Follow Rust best practices for error handling and memory management
Use the macro system (pyclass,pymodule,pyfunction, etc.) when implementing Python functionality in Rust
Files:
crates/stdlib/src/socket.rs
🧠 Learnings (2)
📚 Learning: 2025-06-27T14:47:28.810Z
Learnt from: moreal
Repo: RustPython/RustPython PR: 5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Applied to files:
crates/stdlib/src/socket.rs
📚 Learning: 2025-06-27T14:47:28.810Z
Learnt from: moreal
Repo: RustPython/RustPython PR: 5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
Applied to files:
crates/stdlib/src/socket.rs
🔇 Additional comments (12)
crates/stdlib/src/socket.rs (12)
66-89: LGTM!The Windows WinSock API additions are correctly imported, and
FROM_PROTOCOL_INFO = -1matches the documented WinSock constant value.
991-1054: LGTM!The logic correctly masks out
SOCK_NONBLOCKandSOCK_CLOEXECflags from the stored socket type, ensuring consistent cross-platform behavior. The timeout initialization properly handles non-blocking sockets by setting timeout to 0.0.
1252-1314: LGTM!The AF_ALG address handling correctly validates string lengths against the
sockaddr_algfield sizes and properly initializes the zeroed structure before copying the type and name strings.
1402-1478: LGTM!The Windows socket reconstruction from
share()bytes is correctly implemented with proper size validation,WSASocketWusage, and error handling. The handle inheritance is properly disabled after creation.
1921-2009: LGTM!The
recvmsgimplementation correctly handles buffer allocation, validates input parameters, and properly parses the received data and ancillary data. The return format matches Python'ssocket.recvmsg()specification.
2011-2045: LGTM!The
parse_ancillary_datafunction correctly handles control message iteration with proper truncation handling whenMSG_CTRUNCoccurs. The data length calculation respects both thecmsg_lenfield and the actual available buffer space.
2088-2093: LGTM!Correctly using
CMSG_LENfor thecmsg_lenfield (actual message length) whileCMSG_SPACEis used for buffer allocation (includes padding). This matches the proper CMSG construction pattern.
2111-2141: LGTM with a note on close() error handling.The
__del__implementation correctly emitsResourceWarningfor unclosed sockets, matching Python's behavior. Theclose()error is appropriately ignored withlet _ =since destructors shouldn't propagate errors.
2305-2408: LGTM!The Windows
ioctlimplementation correctly handles the supported IOCTL commands with proper input validation and error handling. TheTcpKeepalivestruct is correctly marked#[repr(C)]for FFI compatibility.
2410-2433: LGTM!The Windows
sharemethod correctly usesWSADuplicateSocketWto create a shareable socket descriptor and returns the protocol info as bytes, which can be used by another process to recreate the socket.
2801-2825: LGTM!The
getaddrinfofunction correctly applies IDNA encoding to hostnames for internationalized domain name support, and properly validates port strings as UTF-8. This matches Python's behavior for hostname encoding.
234-275: These values are correctly defined per RFC 3542 standard and are the appropriate solution for macOS, where they are not available in the libc crate.
Sorry, something went wrong.
45a1940
into
RustPython:main
Dec 29, 2025
Summary by CodeRabbit
New Features
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.