Anyone claiming they can write memory safe / defined C code at scale either has no experience with it or has their head buried in the sand.
-
-
Replying to @CopperheadOS
I don't claim I can write code at scale at all, but if you can, safety need not be significantly harder.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @CopperheadOS
Most unsafety comes from doing backwards things you shouldn't even be doing in modern C.
2 replies 0 retweets 1 like -
Replying to @RichFelker
Use-after-free, double-free, out-of-bounds accesses, etc. happen in every C codebase, even with extreme diligence like SQLite.
2 replies 0 retweets 1 like -
Replying to @CopperheadOS
Use-after-free and double-free shouldn't be able to happen unless you're doing really bad things.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
They do happen in all real world C projects of non-trivial size though. Even when abstracting most forms of lifetime management.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS
You either use single-owner/single-reference, or refcounting. Anything else is idiotic.
1 reply 0 retweets 1 like -
Replying to @RichFelker
Or you use a language like Rust permitting you to do stuff like allocation-free parsing via lots of lightweight safe references.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
It's fine if the compiler tracks the origin of the lifetimes and enforces it. People use C for performance so they will do more.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
Reference counting can also be done wrong. The Linux kernel gets it wrong all over the place even when reusing code for it.
2 replies 0 retweets 0 likes
This is because Linux kernel is full of all sorts of premature-optimization nonsense.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.