[OffTopic] A vulnerability postmortem on Network Security Services

[Paulo Pinto]

On Thursday, 2 December 2021 at 17:43:44 UTC, H. S. Teoh wrote:
> On Thu, Dec 02, 2021 at 11:44:28AM +0000, IGotD- via 
> Digitalmars-d wrote:
>> On Thursday, 2 December 2021 at 11:27:01 UTC, H. S. Teoh wrote:
>> > 
>> > Another nail in the coffin of C.  Still many more nails to 
>> > go, but the inevitable draws ever nearer.
> [...]
>> Would it be impossible to add bounds checking in C?
>> 
>> It's been over 4 decades and it seems like there is some 
>> profound resistance to add this.
>
> C wouldn't be C anymore once it has bounds checking.  You can 
> bet your life that the moment somebody proposes such a thing, 
> complaints about "efficiency" will flare up all over the 
> intarweb.  99% of the C userbase will revolt, and the proposal 
> will be DOA.
>
> Not to mention, how *do* you add bounds checking to a language 
> where arrays automatically and implicitly decay to pointers?  
> No length information is present for you to do bounds checking 
> on. The only way to fix this is to reengineer the language from 
> scratch to introduce bounds-checked arrays.  But that does not 
> fix the problems with the existing standard C libraries which 
> take bare pointers for arrays. *Replacing* current arrays with 
> bounds-checked ones essentially turns it into D, at which point 
> it's not C anymore (see previous paragraph).
>
>
> T

You add it to the hardware, where every memory reference becomes 
a fat pointer, hence C Machines, so Lisp Machines with memory 
tagging, just designed for C instead.

That is how SPARC ADI, ARM MTE work.

Intel borked their MPX execution, so who knows if they will come 
up with something up, given that iOS and Android are now making 
use of hardware memory tagging.