On Mon, 22 Jun 2026 10:57:21 +0200 Andreas Hindborg <[email protected]> wrote:
> David Laight <[email protected]> writes: ... > > I just looked at the code again, the final '- 1' on the 'size = ...' > > line looks very odd. > > It's to leave space for a null char at the end. `fill_item_path` writes > the path from the last segment to the first. But wouldn't that be a '+ 1' ? It might be alright because (IIRC) the length is initialised to one in the helper function. > > > I wonder if it would be simpler to merge all three functions into > > something with a single loop that builds the name/name part backwards > > from the end of the buffer while adding "../" on the front and then > > calling memmove() to put the two together. > > The current implementation is difficult to read for sure. It would be > nice if we can make it more simple to parse. I dislike code that does two passes, one to work out the size and the second to do the work. All too easy for them to get out of sync. One of the pathname functions (but I don't know if this code is used for it) lets the string start part way down the supplied buffer. If it is that case then it could be a lot simpler. It also wouldn't do any hard to try embedding the 'char name[PATH_MAX]' in a structure - so the size is passed implicitly and the compiler can check and humans know what they can do. David > > Best regards, > Andreas Hindborg >
