Am 20.08.2011 17:40, schrieb Walter Bright:
http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
What it does is rewrites the program to install runtime checks on
pointers to ensure no array bounds overflows.
It indicates to me the effort being poured into C to try to make it
memory
On 20/08/2011 16:40, Walter Bright wrote:
http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
What it does is rewrites the program to install runtime checks on
pointers to ensure no array bounds overflows.
It indicates to me the effort being poured into C to try to make it
memory safe,
On 08/21/2011 12:55 PM, Robert Clipsham wrote:
On 20/08/2011 16:40, Walter Bright wrote:
http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
What it does is rewrites the program to install runtime checks on
pointers to ensure no array bounds overflows.
It indicates to me the effort being
Am 21.08.2011, 12:55 Uhr, schrieb Robert Clipsham
rob...@octarineparrot.com:
On 20/08/2011 16:40, Walter Bright wrote:
http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
What it does is rewrites the program to install runtime checks on
pointers to ensure no array bounds overflows.
It
http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
What it does is rewrites the program to install runtime checks on
pointers to ensure no array bounds overflows.
It indicates to me the effort being poured into C to try to make it
memory safe, and how memory safety has become a huge
Walter:
http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
We are on the right track with D with our focus on making D
proveably memory safe.
The paper strategy uses Automatic Pool Allocation:
Automatic Pool Allocation [13] is a fully automatic compile-time
transformation that