Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #10448

About safe and unsafe languages..

Show all headers | View raw

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.

Back to comp.programming | Previous | Next | Find similar | Unroll thread

Thread

About safe and unsafe languages.. aminer68@gmail.com - 2019-12-24 13:00 -0800

csiph-web