5 ms·
How would that work with untrusted strings? As I understood TFA strlen() is an issue if the string is not null terminated
by Phelinofist 4y ago
How would that work with untrusted strings? As I understood TFA strlen() is an issue if the string is not null terminated
- matheusmoreira 4y agoThat's correct. Using strlen on anything but C string literals is just asking for bugs. The thing is untrusted strings don't come from C itself, they come from I/O. The kernel has perfectly reasonable I/O interfaces. ssize_t bytes_read = read(file_descriptor, buffer, size); ssize_t bytes_written = write(file_descriptor, buffer, size); You always know the length. Well... At least you would always know the length if the standard C library didn't abstract that perfectly good interface away behind stdio just so it could do buffering and return NUL-terminated strings. It's just like errno. The kernel simply returns a negated error constant on failure. The C standard library takes that sane interface and turns it into a thread local global variable.
- Gibbon1 4y agoYou could add real strings and arrays to C and kill POSIX and you'd have two fewer problems.
- JdeBP 4y agoNo. You would have extra problems. Not just from the maintenance issues when going along the migration path that Linus Torvalds pointed out. But also especially, for one thing, from the poor thinking generally involved, such as people thinking that the way to address a problem where it is stated that the POSIX API for I/O is reasonable is to "kill POSIX".
- astrobe_ 4y agoApparently at some point people forgot that if you don't like an API, library or interface, you can just put a wrapper on top of it. Many libraries are just "toolkits" after all, you are not supposed to use the raw API everywhere; e.g. you if don't quickly stop doing that with the BSD sockets API, you are part of the problem.
- matheusmoreira 4y ago> if you don't like an API, library or interface, you can just put a wrapper on top of it We can also simply get rid of all that bloat and just use the system calls directly. > you are not supposed to use the raw API everywhere Linux system calls are a stable interface and the entry points are even programming language agnostic. It's okay to use them directly. > e.g. you if don't quickly stop doing that with the BSD sockets API, you are part of the problem Yeah it's not a good idea on other operating systems since the system call interfaces are unstable. We have to use their C libraries on those platforms.
- morelisp 4y ago> Apparently at some point people forgot that if you don't like an API, library or interface, you can just put a wrapper on top of it. If I were to survey the state of modern software development and try to characterize the skills lost compared to decades past, "not enough wrappers" would be nowhere on my list.
- astrobe_ 4y agoOk that was a bit overstated, s/some point people forgot/some people forget/. I don't know what was the common practice a few decades ago because source code was not as visible as it is today, but in my experience what you see on Github is not what the average developer does. Github advertises itself as a social coding network; just like with other social networks, there is a selection bias regarding what is posted.
- astrobe_ 4y ago> That's correct. Using strlen on anything but C string literals is just asking for bugs. The thing is untrusted strings don't come from C itself, they come from I/O. Indeed, it is just an input check/"sanitization" issue - just like one carefully checks that a JSON or XML input is well formed, if a protocol spec says that some part is an ASCIIZ string, one has to check that there's indeed a zero byte before the end of the data packet.