News for hackers. Stuff that matters.
Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by stensal on Monday January 14, 2019 @12:18AM (#18900854)
Thanks a lot for reposting it here. Our original post https://news.ycombinator.com/item?id=18894032 has answered some of the questions you might have.
Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by pag on Sunday January 13, 2019 @08:43PM (#18899974)
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.

Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by stensal on Sunday January 13, 2019 @11:50PM (#18900755)
Nice try bro! That will make C like Java, it will not happen. C should be like just C.
Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by pag on Monday January 14, 2019 @12:47AM (#18900954)
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.
Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by stensal on Monday January 14, 2019 @03:01AM (#18901446)
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.

Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by swiftcoder on Sunday January 13, 2019 @11:17PM (#18900601)
How does this differ from valgrind in practice?
Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by stensal on Monday January 14, 2019 @12:09AM (#18900822)
Ok, The following is the highly level goal. It dictates the design choice and hence the user experience of Stensal SDK.

I want to make C/C++ more user friendly and less scary to beginners. If you love C, you should keep enjoying coding in C and worry less about the memory safety issues. With the advancement of tooling (You will see more advanced static analyzers and runtime analyzers coming out from academia and the industry), it will be less a problem in the future.

The simplicity and portability of C is its key strength that no other languages have. Once the memory safety issue is alleviated, the simplicity of C will help us to build less complex but more functional and reliable code.

C++ is just a completely different beast that I have to support.

Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by Matthias247 on Sunday January 13, 2019 @11:33PM (#18900671)
and memory/address-sanitizer, which are super helpful too
Re:Stensal SDK: Retrofitting C/C++ code with quasi-memory-sa... by stensal on Monday January 14, 2019 @12:16AM (#18900849)
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 [email protected]. What communication method do you prefer? a mailing list.