3 ms·
In 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
by roca 7y ago
In 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".