From: d@d.d   
      
   Hello,   
      
      
   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: you cannot sedate... all the things you hate (1:229/2)