3 ms·
Yes, 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 safe
by quotemstr 7y ago
Yes, 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".