crates/vm/src/stdlib/_ctypes.rs (1)

546-557: ⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Preserve Python error propagation in LoadLibrary (avoid panic).

Line 555 uses unwrap() inside a Python-callable function. On library load failure this can panic the VM instead of raising an exception.

Proposed fix

- fn load_library_windows(
+ fn load_library_windows(
     name: String,
     _load_flags: OptionalArg<i32>,
     vm: &VirtualMachine,
-) -> usize {
+) -> PyResult<usize> {
   let cache = library::libcache();
   let mut cache_write = cache.write();
-  let (id, _) = cache_write.get_or_insert_lib(&name, vm).unwrap();
-  id
+  let (id, _) = cache_write
+      .get_or_insert_lib(&name, vm)
+      .map_err(|e| vm.new_os_error(e.to_string()))?;
+  Ok(id)
 }

🤖 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/vm/src/stdlib/_ctypes.rs` around lines 546 - 557, The function
load_library_windows currently calls cache.write().get_or_insert_lib(&name,
vm).unwrap() which can panic; change load_library_windows to return
PyResult<usize> (instead of usize) and propagate the error instead of
unwrapping: call get_or_insert_lib(&name, vm) and map or match its Err to a
Python exception via the VirtualMachine (e.g. vm.new_os_error or an appropriate
vm.new_exception with a descriptive message), returning Err(...) on failure, or
use the ? operator after converting the error into a PyResult to return the id
on success; keep references to library::libcache(), cache.write(), and
get_or_insert_lib to locate the code.

crates/vm/src/stdlib/_ctypes/base.rs (2)

2465-2495: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Avoid pointer-size fallback for unknown field types.

Line 2494 defaults to size_of::<usize>() when size resolution fails. That can let invalid _fields_ entries pass with a bogus size instead of failing fast with TypeError.

Suggested direction

-pub(super) fn get_field_size(field_type: &PyObject, vm: &VirtualMachine) -> usize {
+pub(super) fn get_field_size(field_type: &PyObject, vm: &VirtualMachine) -> PyResult<usize> {
  ...
- core::mem::size_of::<usize>()
+ Err(vm.new_type_error("field type has no determinable ctypes size"))
}

Update callers in structure/union/CField initialization to propagate this error.

🤖 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/vm/src/stdlib/_ctypes/base.rs` around lines 2465 - 2495, Replace the
pointer-size fallback in get_field_size by returning a failure instead: change
get_field_size to return Option<usize> (or Result<usize, PyErr>) instead of
usize, remove the final core::mem::size_of::<usize>() default and return
None/Error when no size could be resolved, and then update all callers (e.g.,
the structure/union initialization paths and CField construction sites that
currently call get_field_size) to check the Option/Result and propagate a
TypeError via the VM (e.g., vm.new_type_error or equivalent) when size
resolution fails so invalid _fields_ entries fail fast.

---

1590-1643: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Do not silently zero-fill failed ctypes conversions.

Line 1642 (and unwrap_or(0) at Lines 1624, 1628, 1632, 1636) turns invalid/out-of-range assignments into zero bytes instead of raising, which can silently corrupt structure/union field data.

Suggested direction

-fn value_to_bytes(value: &PyObject, size: usize, vm: &VirtualMachine) -> Vec<u8> {
+fn value_to_bytes(value: &PyObject, size: usize, vm: &VirtualMachine) -> PyResult<Vec<u8>> {
   ...
-  _ => vec![0u8; size],
+  _ => {
+      return Err(vm.new_type_error(format!(
+          "cannot convert {} to ctypes field value",
+          value.class().name()
+      )));
+  }
}

Then propagate ? at call sites where assignment must fail on invalid conversion.

🤖 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/vm/src/stdlib/_ctypes/base.rs` around lines 1590 - 1643, The helper
value_to_bytes currently silently zero-fills on failed numeric conversions (uses
unwrap_or(0) and returns zero bytes), which hides errors; change value_to_bytes
to return a PyResult<Vec<u8>> (or Result) and propagate conversion failures
instead of substituting zeros: replace the unwrap_or(0) calls in value_to_bytes
and the final fallback path so that when int conversions via value.try_int(vm)
or bigint->to_i8/to_i16/to_i32/to_i64 fail you return an appropriate Python
error (e.g. OverflowError/TypeError via the VirtualMachine) instead of producing
zero bytes, and likewise make float/int size-mismatch cases return an error
rather than unreachable/zero-fill so callers of value_to_bytes (e.g. code using
PyCData) can handle the failure.