3 ms·

It simplifies implementations. For example, typically you need to be able to store paths in a consecutive area of memory or storage. Knowing that paths don't ex

It simplifies implementations. For example, typically you need to be able to store paths in a consecutive area of memory or storage. Knowing that paths don't exceed a certain size means you can know that a particular allocation strategy (like static allocation, for a simple example) will be sufficient.

klodolph 10y ago
Mostly it's for stuff like readlink(), which returns a path in a user-supplied buffer. How big should the buffer be? The Linux man page actually suggests doing lstat() to size the buffer, with a note that this is susceptible to a race condition!
- dom0 10y ago
  readlink(2) takes a buffer and the buffer's size, so it's safe. You just enter a race-controlled loop, as always.
  - klodolph 10y ago
    I should have been clearer: the complaint was about the API usability, not about safety. The POSIX API is a total mess when it comes to things like this.
jerf 10y ago
I don't question that using wrong values can simplify implementations. But if we're going to complain about people using inconsistent lengths, what's the consistent one they should be using? If you can't name one than the inconsistency criticism is null. As long as I'm already typing, the real problem here is that path lengths do not in fact fit into any practical statically-sized buffer. While statically-sized buffers have their utility and aren't going anywhere, they're an optimization, or a special case, in a world that is fundamentally dynamically-sized. In the 1970s it made sense for hardware reasons to treat "static buffer" as the default case and make dynamically-sized buffers the harder case, but that's not correct today on any level, code correctness, developer convenience, API cleanliness, ease of use, anything. Yes, I understand that this is a kernel API and I am aware I'm making a deep structural criticism of UNIX kernels here, and that fixing it would be a significant challenge. It would take quite a bit of fundamental rethinking of how things work to do something like pass the kernel a function pointer to allocate a given bit of user-space RAM or something, or pass it a static buffer with a function to call on overflow, or something, and I am not claiming this would be easy. (Note the distinction between "dynamically sized" and "arbitrarily large"; a 3GB path is 99.9999+% either some sort of bug or an attack, so having a total max path length has advantages too. But you can do something like make it 1MB, something very generous, without making everything that uses paths allocate 1MB per path.)
- jstimpfle 10y ago
  I can understand your side, but on the other hand... I'm sure there are a lot of (sub)systems even today that just can't have objects larger than 4096 bytes. Also has 4096 bytes ever been restricting to you? I once heard from someone doing evil things and hitting NAME_MAX, but there is no problem just treating that rare case as some sort of I/O error. Everything IO can always fail anyway.

klodolph 10y ago

Mostly it's for stuff like readlink(), which returns a path in a user-supplied buffer. How big should the buffer be? The Linux man page actually suggests doing lstat() to size the buffer, with a note that this is susceptible to a race condition!

dom0 10y ago
readlink(2) takes a buffer and the buffer's size, so it's safe. You just enter a race-controlled loop, as always.
- klodolph 10y ago
  I should have been clearer: the complaint was about the API usability, not about safety. The POSIX API is a total mess when it comes to things like this.

jerf 10y ago

I don't question that using wrong values can simplify implementations. But if we're going to complain about people using inconsistent lengths, what's the consistent one they should be using? If you can't name one than the inconsistency criticism is null. As long as I'm already typing, the real problem here is that path lengths do not in fact fit into any practical statically-sized buffer. While statically-sized buffers have their utility and aren't going anywhere, they're an optimization, or a special case, in a world that is fundamentally dynamically-sized. In the 1970s it made sense for hardware reasons to treat "static buffer" as the default case and make dynamically-sized buffers the harder case, but that's not correct today on any level, code correctness, developer convenience, API cleanliness, ease of use, anything. Yes, I understand that this is a kernel API and I am aware I'm making a deep structural criticism of UNIX kernels here, and that fixing it would be a significant challenge. It would take quite a bit of fundamental rethinking of how things work to do something like pass the kernel a function pointer to allocate a given bit of user-space RAM or something, or pass it a static buffer with a function to call on overflow, or something, and I am not claiming this would be easy. (Note the distinction between "dynamically sized" and "arbitrarily large"; a 3GB path is 99.9999+% either some sort of bug or an attack, so having a total max path length has advantages too. But you can do something like make it 1MB, something very generous, without making everything that uses paths allocate 1MB per path.)

jstimpfle 10y ago
I can understand your side, but on the other hand... I'm sure there are a lot of (sub)systems even today that just can't have objects larger than 4096 bytes. Also has 4096 bytes ever been restricting to you? I once heard from someone doing evil things and hitting NAME_MAX, but there is no problem just treating that rare case as some sort of I/O error. Everything IO can always fail anyway.