Re: Ada's Slide To Oblivion ...

["David Thompson" <david.thompson1@worldnet.att.net>]

Nick Roberts <nickroberts@adaos.worldonline.co.uk> wrote :
...
> Allow me to try to clarify. The C language requires (in practice if not
> strictly in theory) that all pointers fit into one machine word.

Not really.  Early versions of C did this (and BCPL and B required it),
but as C became more widely ported and (then) standardized it was
recognized by everyone who was paying attention that you cannot
assume this: "all the world's not a VAX".  It is true that C tends to
stress use and particularly computation of pointers, which puts
a premium on lightweight pointers, where possible.

> On 32-bit
> architectures, this almost invariably forces the use of a 'flat' address
> space (just an offset, with no segment number or equivalent). Which means
> that, for many architectures, the operating system cannot use segmentation
> (or other memory divisions) to [restrict executability]

Only on 32-bit architectures where the segment is (always)
outside the 32-bit address, like 386+.  I have seen several
architectures that put segment+offset into a 32-bit address,
which can work as you want.  Admittedly certain x86 systems
are so widely used that problems on them affect a lot of people,
but I don't think the language is solely or even primarily to blame.

> On many architectures, then, C prevents the OS from using available memory
> protection mechanisms to prevent buffer overrun exploitation, whereas most
> other programming languages do not. In this way, C is a security liability.

Most generalpurpose 3GLs have some way of creating and using
pointers, at least in the form of by-reference argument passing.
It is equally illegal in all these languages to actually overrun a
buffer, and in usual implementations of all of them it is possible
to do so anyway, although almost never as easily as is usual in C,
and if you do the results are equally damaging.

> C++ generally has the same fault.

Except to the extent that you use containers like std::vector
or other encapsulated and checked types and operations
to prevent overruns in the first place.  But you certainly aren't
required, or even all that strongly encouraged, to do so.

--
- David.Thompson 1 now at worldnet.att.net