Without changing how people write code, how difficult is it to implement some kind of memory-safety feature (even if not accurate) in a C compiler, so it can show some kind of warning at least?If it can't be done so easily at compile-time, then what about some kind of static-analysis tool that can inspect binaries for potential violations?
>>107875819sounds good oponce you get that figured out, you should write a static analysis tool that can determine whether a program will stop or continue executing forever
>>107875819All you need is linear types.
>>107875819already existshttps://fil-c.org/
>>107875819just use the flag to enable ASAN.Pro mode: enable MSAN.Also enable UBSAN, if this works.Too bad you can't have TSAN at same time too.
>>107875819>so it can show some kind of warning at leastrust doesn't do that either, it just crashes
>>107875819The best way is to write as much of your C code as possible without allocating memory.https://nullprogram.com/blog/2018/06/10/
>>107876443This dude has all the best ideas and the worst coding style ever.
just use valgrind
>>107875819It already warns for some stuff.Warning for every single problem is both hard to retrofit and impossible to do without also warning for some stuff that's actually safe.>>107876129It does for bounds checks but not for most other things like use-after-free and data races. Those are caught at compile time.
you only need heap memory when you dont know how much you need, or if you need massive amounts of it. there are reference counting pointer implementations for C, and the linux kernel even uses them. you should valgrind though at runtime to check for leaks.
