Svadev mailing list

["Adve, Vikram Sadanand" <vadve AT illinois.edu>]

That is true, but I think the SAFECode run-time should intercept the SIGSEGV 
signal and shut down the program with an SVA/SAFECode error message, rather 
than a standard segfault.  This matters if you want to claim that SAFECode 
makes C/C++ close to a safe language.  Technically, a safe language makes 
segfaults impossible.

A strict, type safe language would disallow the write itself.  But in 
practice for C/C++, this will reduce to detecting the illegal write at 
run-time and shutting down the program, so letting the MMU do the detection 
for us, whenever possible, is the most efficient way to do it.

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve



On Mar 5, 2011, at 2:49 PM, John Criswell wrote:

> On 3/5/11 2:43 PM, Matthew Wala wrote:
>> It seems that SAFECode silently allows you to modify string literals,
>> even when the intended memory operation segfaults the original
>> program.
>> Shouldn't this be considered a memory safety error?
> 
> It depends on what you call a memory safety error.
> :)
> 
> As far as SAFECode is concerned, writing into a string literal or into 
> some other global memory object marked constant is okay because it is 
> not an out-of-bounds write.  SAFECode does not enforce read-only 
> attributes; it will permit writes to memory that are marked constant, 
> for example.  Fortunately, such memory is usually made read-only by the 
> OS, so the MMU enforces the read-only attribute of the memory object.
> 
> -- John T.
> 
> 
>> _______________________________________________
>> svadev mailing list
>> svadev AT cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/svadev
> 
> _______________________________________________
> svadev mailing list
> svadev AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/svadev