[kreco]

The mental overhead is pretty significant.

You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename. You can't just toss a contiguous number of bytes you to convert it first.

Every single piece of software that need to interact with the file system needs to deal with this.

I'm not asking about a new string type. I'm asking to be able to be free from null terminating string.

You only need to provide a length.

[phicoh]

In practice, with Rust the problem is somewhere else. There is a libc crate that wraps the Unix system calls, so no need to worry about that. What is a lot harder is that Unix filenames are not guaranteed to be UTF-8. So you can't convert to &str or String. At least, not without loss. So you have to keep this around as an OsString.

[kreco]

Yeah that's the kind of thing I'm talking about.

Even when you don't care about being cross-platform, you still need to rely on specific routines instead of having the most low level `ut8fopen(buffer, len, mode);`

My point is that I wish we would have a new "standard OS-related API", not even talking about introducing span type or anything, just creating something way more sane and care about moving forward from this point.

If I was about to create my own OS and decided to eliminate null-terminating string, and keep it as tiny and efficient as possible, I would face so many issues because I cannot reuse 99% of the code (related to file API) that already exists, I would need to think how to properly parse arguments from "main" without overhead etc.