News for hackers. Stuff that matters.
Re:Fil-C: A memory-safe C implementation by ummonk on Wednesday October 29, 2025 @12:54PM (#45749588)
No, it should only do arithmetic on the first 64 (or 32) bits. The extra metadata should be copied unchanged.
Re:Fil-C: A memory-safe C implementation by kbolino on Wednesday October 29, 2025 @01:29PM (#45750188)
Ok, I think I follow. You'd widen the type under the hood but not expose this fact to user code.

However, most longs are just numbers that have no metadata. I guess you'd set the metadata portion to all zeroes in that case. This feels like a reified version of Rust's pointer provenance, and I think you would have to expose some metadata-aware operations to the user. In which case, you're inviting some code rewrites anyway.

While not as bad as the register/ALU ops issue, you're still making all code pay a storage size penalty, and still adding some overhead to handle the metadata propagating through arithmetic operations, just to accommodate bad code, plus it complicates alignment and FFI.

Re:Fil-C: A memory-safe C implementation by ummonk on Wednesday October 29, 2025 @02:24PM (#45750992)
It would still be exposed to user code that checks its size with sizeof, but yeah the long would only have numerical values between 2^-63 and 2^63-1.

And yes, there would still be some overhead for storing and propagating the metadata, and struct alignment would change and FFI wouldn't work with longs.

Re:Fil-C: A memory-safe C implementation by ummonk on Thursday October 30, 2025 @07:35AM (#45758881)
Err I meant -2^63, that’s embarrassing.
Re:Fil-C: A memory-safe C implementation by kragen on Saturday November 01, 2025 @11:11AM (#45782266)
Heh. I missed that.