> The frustrating thing about rings of protection is that there have been machines which had the right hardware, but no OS used it. [...] C and UNIX/Linux want

> The frustrating thing about rings of protection is that there have been machines which had the right hardware, but no OS used it. [...] C and UNIX/Linux want a big flat address space and a vanilla CPU. C per se does not want flat address space: it is, for example, UB to subtract pointers that do not point within a same object. IOW, "far pointers" from the DOS era and segmented 286-style pointers would absolutely be within the bounds of the C standard, if they hadn't used special syntax. With 386 segment-level protection you could define one segment per object, with byte-level granularity limit checks for segments smaller than 1MB. Each string could have had its own segment with precise length. No more buffer overruns. I think we ended where we are now because of several factors: 1. early hardware -- 286 -- was too limiting. Each segment could be at most 64k long, and 2. programmers (naturally) needed arrays larger than 64k even back then, 3. OS-es, UNIX and Win32, but not VMS, targeted the lowest common HW denominator, which is flat address space with only U/S page protections, 4. rather bad tooling. Situation is changing slowly though. Intel's MPX extension offers much of the old segment-level protection, but is opt-in for software and needs tooling support (compiler, linker, loader, etc). This is being worked on, e.g., in gcc: http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20G...