
Stensal SDK: Retrofitting C/C++ code with quasi-memory-safety - pjmlp
https://stensal.com/
======
stensal
Thanks a lot for reposting it here. Our original post
[https://news.ycombinator.com/item?id=18894032](https://news.ycombinator.com/item?id=18894032)
has answered some of the questions you might have.

------
pag
One unusual thing is that, at least for the curl example binary, the pre-built
installable version is an x86 one and not an x86-64 one.

From briefly looking at the assembly, it seems like each variable or stack
object has metadata associated with it in the stack frame. Some of this
metadata seems pretty heavyweight, e.g. having `0xDEADBEEF` as a magic
constant, what looks like the size, a pointer to a global variable, etc. One
worry is that this metadata appears adjacent to memory it protects.

I wonder if it would be easier to just make all local variables into heap
allocations and handle things uniformly there. This would make it easier to
upgrade the runtime in the future without requiring recompilation.

~~~
stensal
Nice try bro! That will make C like Java, it will not happen. C should be like
just C.

~~~
pag
I think you could produce much better machine code by "templatizing" the stack
allocations into function-specific pattern variables, passed to a single
alloca-like function which uses the template to figure out how much stack
space to allocate, displaces the stack pointer, and sets up all your metadata
in one swoop. Also, this would improve the upgradability of the
runtime/metadata, as it would be decoupled.

~~~
stensal
Heap is a centralized resource. Each allocation/free will have to
acquire/release lock. It's much more costly than stack
allocation/deallocation. You might get more efficient machine code, but using
heap will likely cost more.

Hope this clarify what I meant your idea will make C like Java.

------
swiftcoder
How does this differ from valgrind in practice?

~~~
Matthias247
and memory/address-sanitizer, which are super helpful too

~~~
stensal
If ASAN/MSAN works for you well that's great.

You want to give Stensal SDK a try, you will find it's easier to use provided
Stensal SDK can build your code. If you have any problems, feel free to send
bugs report to support@stensal.com. What communication method do you prefer? a
mailing list.

