3 ms·
Thread-safe refcounts or not? Do you have separate types for "mutable owned string" and "immutable ref-counted string"? Small-string optimizations? You may thin
by roca 7y ago
Thread-safe refcounts or not? Do you have separate types for "mutable owned string" and "immutable ref-counted string"? Small-string optimizations? You may think there's a single obvious answer for all these decisions but major libraries for other languages have made different decisions for each one.
Refcounted strings are actually very nasty to use in C because you have no RAII or other automatic memory management. You have to manually deref every string value when it goes out of scope, or get leaks --- and if you accidentally ever double-deref along some path, you get probably-exploitable use-after-free.
Once you've picked some tradeoffs for your program, you have to live with the fact any foreign C you call isn't using your library so you'll be converting to/from their types (typically const char*) all over the place anyway, so the temptation to "just use chars" will be ever-present.
Given those issues, I'm not surprised I actually haven't seen any C programs use this model.
- quotemstr 7y agoYes, these are all questions you need to answer. Thing is, no matter how you answer these questions, what you produce is still far more convenient and much safer than random char buffers everywhere. If sudo had a 200 line internal string library, this vulnerability wouldn't have happened. There's no excuse for open coding lots of random string stuff.
- roca 7y agoIn C it can't be more convenient than, say, char buf[16]; sprintf(buf, "/proc/%d/mem", pid); int fd = open(buf, O_RDONLY); If you accidentally double-free or have UAF along some error path, then it's not safer either (given compilers have strong mitigations for stack buffer overflows these days, but not double-free or UAF).
- quotemstr 7y agoLOL. > char buf[16]; sprintf(buf, "/proc/%d/mem", pid); int fd = open(buf, O_RDONLY The code you're using to demonstrate the simplicity of char arrays has a buffer overflow vulnerability: what happens when the input int is large? You're proving my point. In practice, dynamic resource allocation doesn't lead to rampant use after free bugs, especially if you follow regular and simple rules for ownership. It certainly results in fewer bugs and fewer severe bugs than cowboy char arrays code.
- roca 7y ago> The code you're using to demonstrate the simplicity of char arrays has a buffer overflow vulnerability: what happens when the input int is large? You're proving my point. I did that deliberately to show how tempting, but also dangerous, it is to use char buffers in C. I'm not advocating char buffers. I'm advocating not using C, and not buying arguments of the form "C's fine if you just do this thing that no-one does".