stensal

I changed it to "dynamic pointer typing". Thanks for your questions.

I want to avoid to do comparison with the said X tool without fully understanding their constraints because different approaches have made different design trade off and each has its own strength. That having been said, the academia often publish some survey papers about the state of art of memory error detection tools. There is a recent paper "SoK: Sanitizing for Security"(https://arxiv.org/abs/1806.04355) that has categorized most of the known dynamic memory error finding tools very well. They analyzed the different detection mechanisms and collected empirical data with their best efforts in their categorization. It's highly recommended for anyone who wants to understand the difference among these detection tools.

IMHO, If you want to increase your detection coverage. You might need multiple tools to fulfill your code quality requirements. If you cannot use multiple tools, pick the one that is readily available.

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.

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.

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.

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.

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

As you have rightly pointed out the intended use case. I want to add more constraints to it. It's intended to be used in production deployments that are security critical, constant applying security patches is not an optimal solution, and slowdown is bearable.

It will introduce denial of service attack. QMS executables can operate in two modes: warning mode and crash mode. Both will reduce the level of service, but neither will allow memory accession violations to happen.

Edit: added more constraints to the suitable production deployments.

(1) It is not designed to find more memory errors than said X tool. It is designed to find complete runtime memory errors that can cause security concerns, more specifically, like remote code execution and information leakage (like heartbleed) with very high probability. The probability is determined statically by source code pattern instead of the permutation of malicious input. In theory, you can intentionally write code that cause the runtime checking fail to catch a runtime error.

The minimal code example: Try to iterate the CLI argument of this code snippet https://stensal.com/a/demo_reporting, Valgrind and Asan will not report the overrun when the input is larger than certain numbers.

(2) It currently supports C++14. It will be upgraded in the future releases to support C++17. It is based on the great LLVM/Clang compiler framework.

(3) CI server needs a group license with discount. If all individual developer already has license, there is no need for extra license.

(4) Slowdown can be optimized based on user requirements.

No, the pointer always has the native pointer size. I think the type in my use of "dynamic type system" confused you. The type has a very narrow meaning, it has only two values. It is either POINTER or NON_POINTER. A POINTER type is like a tuple of size and liveness. It does not track the static types like integer, float, or struct, etc. Hope this clarify it. Perhaps, I should call it 'dynamic pointer tracking system'. Does it sound more clear?

Yes, you have stated it correctly. The size and liveness information are from allocations (either stack or heap). ASAN and Valgrind do not associate these information with pointers, but add redzones (extra paddings with special bit patterns) before and after each legit memory block. It only triggers error reporting if a pointer happens to point to one of the redzones. However, redzones always have limited sizes. They cannot cover the ranges of out-of-bound pointers.

It's dynamic typing.

I didn't know SillyMUD. But I did read the paper about an interpretation based memory checking tool many years ago. Unfortunately, I forgot the name. I believe the interpretation based memory checking tool assigns each pointer a type. So the idea is not new.

ASAN is great because of its compatibility with existing libraries, as you have pointed out, is available in both gcc/clang. Valgrind is in the same league. Both are fantastic tools even though they might miss some errors.

I guess you ask how this dynamic type system works. It basically gives each valid pointer a type, which includes the size information and liveness information of memory pointed by the pointer. When a pointer is dereferenced, the runtime checking will verify whether the dereference is valid. Null (and uninitialized) pointer does not have a type.

It uses a completely different mechanism from the one used by ASAN and Valgrind.

Edit: delete a wrong answer.

I'm the founder and built the SDK.

Agreed, ASAN and Valgrind cover the most memory errors and are readily available for almost all platforms.

The SDK is designed for a different purpose -- to catch all runtime memory issues with a very high probability. The generated executables can be deployed and used by the end users who don't want to upgrade just for the fixes of memory errors. There are many cases the memory errors are never exploited. By using the pre-built QMS executables, you know when you are exploited, and the exploit will be stopped by the runtime checking.

Edit: Even though I have been reading HN for a quite long time. This is my first post, I just registered recently. I could not figure out how to post Show HN and had to ask a friend to post it for me.

Added more details.