You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Core: Carry signedness from every declaration and inference site
Sign now originates wherever a type is declared or inferred, and emitted IR
changes only where a value is widened out of a type now known to be unsigned:
- Helper return types are typed per the kernel signature: ktime_get_ns,
get_current_pid_tgid, get_current_uid_gid, get_current_cgroup_id,
get_prandom_u32 and get_smp_processor_id are unsigned; the probe_read
family, perf_event_output and get_stack return long.
- Undeclared locals are 64-bit with the sign of their initializer -- from the
helper registry for helper results, and for binary operations from a small
static inference (expr/type_inference.py) applying the same usual arithmetic
conversions the code generator will.
- Integer literals are typed as C types them (int if it fits, else long long)
while remaining 64-bit constants; this rank is what makes u32 / -2 promote
to an unsigned 32-bit division.
- signedness() understands vmlinux Field descriptors, and load_ctx_field
sign-extends signed sub-64-bit context fields instead of always
zero-extending them.
- printk widening goes through convert.
Two sites decided whether to emit a conversion from descriptor *equality*.
With literal descriptors now narrower than the constants that carry them, that
skipped required truncations (storing an i64 into an i32 slot). Assignment and
the ctypes cast handler now always run convert, which is a no-op when the
physical widths already agree.
Corpus: the following programs change, every changed line a sext->zext swap on
a value of known unsigned type:
failing_tests/xdp/xdp_test_1.py.ll
passing_tests/assign/augassign_struct_field.py.ll
passing_tests/helpers/smp_processor_id.py.ll
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BSDVsZH5NtoASyxB8FCtGU
0 commit comments