You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once factor that makes dealing with Paths somewhat awkward at the moment is the requirement for a trailing null. For example, I cannot have a split_at(&self, n: usize) -> (&Path, &Path) function because the first part would not have a trailing null. But allocating a PathBuf would often be wasteful because it might be discarded directly, or may only be used for comparison and not for a littlefs2 API call.
We could support this by introducing a third path type that does not require a trailing null, let’s call it PathView. It could be created without overhead from a PathBuf or Path and could be used for comparison. To use it with a littefs2 API call, it would need to be converted to a PathBuf.
Do you think it is worth having a separate type for this or should we just accept the current limitations?
The text was updated successfully, but these errors were encountered:
An alternative could be to make the trailing null byte in Path optional. littlefs2 could then internally copy paths to a buffer to add the trailing null if needed.
Once factor that makes dealing with
Path
s somewhat awkward at the moment is the requirement for a trailing null. For example, I cannot have asplit_at(&self, n: usize) -> (&Path, &Path)
function because the first part would not have a trailing null. But allocating aPathBuf
would often be wasteful because it might be discarded directly, or may only be used for comparison and not for a littlefs2 API call.We could support this by introducing a third path type that does not require a trailing null, let’s call it
PathView
. It could be created without overhead from aPathBuf
orPath
and could be used for comparison. To use it with a littefs2 API call, it would need to be converted to aPathBuf
.Do you think it is worth having a separate type for this or should we just accept the current limitations?
The text was updated successfully, but these errors were encountered: