News for hackers. Stuff that matters.
Re:Chromium project finds that 70% of security defects are m... by Gibbon1 on Sunday May 24, 2020 @04:52AM (#23290181)
I saw an essay by someone discussing going back to C and eschewing leet pointer and decentralized memory allocation for a system of centralized memory allocation and passing handles[1] instead of pointers. Which appeared to make most of the memory safety problems go away.

[1] handles could be unboxed to expose a pointer. But unboxing had machinery to detect and trap on bad handles

Re:Chromium project finds that 70% of security defects are m... by fpoling on Sunday May 24, 2020 @05:15AM (#23290281)
That reminds me about early Fortran where everything was statically allocated including local variables and function return address. To simulate data structures one used arrays of various dimensions. Effectively array indexes where handles. This was not memory safe as there were no bounds checks. But add those when the compiler cannot eliminate them, and one gets fast and memory safe language.

Edit: that static allocation was essentially a centralized store. Everything repeats itself.

Re:Chromium project finds that 70% of security defects are m... by fetbaffe on Sunday May 24, 2020 @06:53AM (#23290678)
Re:Chromium project finds that 70% of security defects are m... by Gibbon1 on Sunday May 24, 2020 @04:53PM (#23294611)
That's the essay. I think it's interesting because he's mimicking the way I've been writing firmware. I've found most of the issues with memory safety disappear when you use static and centralized resource allocation, avoid monkeying with pointer arithmetic, and avoid making temporary copies of pointers 'for later'.