Hello..


About safe and unsafe languages..

We use the term safe to refer to languages that automatically perform
runtime checks to prevent programs from violating the bounds of
allocated memory. Safe languages must provide two properties to ensure
that programs respect allocation bounds: memory safety and type safety.

Memory safety is the real goal, it means that the program will not read
or write data outside the bounds of allocated regions. To achieve memory safety, a language must also enforce type safety so that it can keep
track of the memory allocation bounds. Without type safety, any
arbitrary value could be used as a reference into memory.

Beyond the possibility of buffer overflow, unsafe languages, such as C
and C++, value compile-time optimization and concise expression over
safety and comprehensibility, which are key features of safe languages.
This difference in priorities is evidenced by the fact that most unsafe languages allow programs to directly access low-level system resources, including memory. In contrast, safe languages must explicitly control
the ways programs are allowed to access resources, to prevent violations
of the properties that they guarantee.

Fundamental to the trade-off between safe and unsafe languages is the
concept of trust. Unsafe languages implicitly trust the programmer,
while safe languages explicitly limit the operations that they allow in exchange for the capability to prevent programs from making potentially damaging mistakes. The result is that unsafe languages are more powerful
with respect to the operations that can be performed, while safe
languages provide greater reusable functionality with built-in
protections that often make programmers more efficient. Another
side-effect of a small set of low-level operations is that complex
problems can typically be solved more concisely in unsafe languages,
which is often seen as another advantage over safe languages.

Many of the distinctions that often accompany the difference between
safe and unsafe languages are technically unnecessary. It is possible to implement a safe language that provides a small instruction set and
low-level access to nonmemory resources, such as the network and
filesystem. However, because the additional record keeping and checks
required to make a language safe degrade the performance of compile-time optimization strategies, memory-safe languages have typically been
deemed unacceptable for certain types of programs. Recently, security
concerns have prompted limited reconsideration of these tradeoffs. Safe languages designed with performance and flexibility in mind have been
created in academic circles and have been shown to effectively prevent
buffer overflow vulnerabilities, albeit at a performance cost. The
section on safe C dialects gives an overview of two of the more complete implementations.



Thank you,
Amine Moulay Ramdane.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Read this:


As you have noticed i have just posted previously about
safe languages like ADA and unsafe languages like C and C++,
now i will write more about safe and unsafe languages:

About safe and unsafe languages..

We use the term safe to refer to languages that automatically
perform runtime checks to prevent programs from violating the
bounds of allocated memory. Safe languages must provide two
properties to ensure that programs respect allocation bounds:
memory safety and type safety.

Memory safety is the real goal, it means that the program
will not read or write data outside the bounds of allocated
regions. To achieve memory safety, a language must also enforce
type safety so that it can keep track of the memory allocation
bounds. Without type safety, any arbitrary value could be used
as a reference into memory.

Beyond the possibility of buffer overflow, unsafe languages,
such as C and C++, value compile-time optimization and concise
expression over safety and comprehensibility, which are key
features of safe languages. This difference in priorities is
evidenced by the fact that most unsafe languages allow programs
to directly access low-level system resources, including memory.
In contrast, safe languages must explicitly control the ways
programs are allowed to access resources, to prevent violations
of the properties that they guarantee.

Fundamental to the trade-off between safe and unsafe languages
is the concept of trust. Unsafe languages implicitly trust the
programmer, while safe languages explicitly limit the operations
that they allow in exchange for the capability to prevent programs
from making potentially damaging mistakes. The result is that
unsafe languages are more powerful with respect to the operations
that can be performed, while safe languages provide greater reusable functionality with built-in protections that often make programmers
more efficient. Another side-effect of a small set of low-level
operations is that complex problems can typically be solved more
concisely in unsafe languages, which is often seen as another
advantage over safe languages.

Many of the distinctions that often accompany the difference
between safe and unsafe languages are technically unnecessary.
It is possible to implement a safe language that provides a
small instruction set and low-level access to nonmemory
resources, such as the network and filesystem. However,
because the additional record keeping and checks required
to make a language safe degrade the performance of compile-time
optimization strategies, memory-safe languages have typically
been deemed unacceptable for certain types of programs.

Recently, security concerns have prompted limited reconsideration
of these tradeoffs. Safe languages designed with performance and
flexibility in mind have been created in academic circles and
have been shown to effectively prevent buffer overflow
vulnerabilities, albeit at a performance cost. The section on
safe C dialects gives an overview of two of the more complete
implementations.


Thank you,
Amine Moulay Ramdane.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)