code wiki / _hdl_build / _trunc_probe.nx

_trunc_probe.nx

buildroot/runtime/_hdl_build/_trunc_probe.nx

2473 B46 linesdepth 2pulls 2 transitivereach 0 importersview sourcekind probe

docs dependencies structs consts functions

about

_trunc_probe.nx -- ROOT-CAUSE probe for LM-022 (operator: audit workarounds, fix roots not bolt patches). The constant O_WRONLY_CT=0x241 INCLUDES O_TRUNC in both syscalls files -- so does sys_openat_wr ACTUALLY truncate? If yes, LM-022 is STALE and the pad-newlines + sibling-tmp+renameat workarounds sprinkled everywhere are UNNECESSARY (the single biggest de-bolting). If no, it is a real bug to fix. Empirical, in nx: write a LONG file -> reopen w/ sys_openat_wr, write SHORT -> read back. TRUNCATES if the readback is EXACTLY the short content (no stale tail). license_tier: ORIGINAL

dependencies 1 imports · 0 importers

imports: nx_syscalls.nx

imported by: nobody (leaf or entry point)

call flow from main pre-order; caps 40 nodes / depth 6 declared; ↻ = already shown

structs

none

consts

none

functions

10	func tp_p(s: *u8) -> i64 { var n: i64=0; while s[n]!=(0 as u8){n=n+1} sys_write(1,s,n); return 0 } called by 1: main calls 1: sys_write
11	func tp_n(v: i64) -> i64 { let bb: u8=sys_mmap(28); var m: i64=v; var t: u8=sys_mmap(28); var k: i64=0; if m==0{t[0]=48 as u8;k=1}; while m>0{t[k]=(48+(m%10)) as u8;m=m/10;k=k+1}; var i: i64=0; while i<k{bb[i]=t[k-1-i];i=i+1}; sys_write(1,bb,k); return 0 } called by 1: main calls 2: sys_mmap sys_write
12	func tp_write(path: u8, s: u8, n: i64) -> i64 called by 1: main calls 3: sys_openat_wr sys_write sys_close
19	func main() -> i64 calls 8: tp_p tp_write sys_mmap sys_openat_rd sys_read sys_close+2