diff --git a/lib/std/c/haiku.zig b/lib/std/c/haiku.zig index 300dc9076c..30ab3542b9 100644 --- a/lib/std/c/haiku.zig +++ b/lib/std/c/haiku.zig @@ -372,7 +372,9 @@ pub const KERN = struct {}; pub const IOV_MAX = 1024; pub const PATH_MAX = 1024; -pub const NAME_MAX = 256; +/// NOTE: Contains room for the terminating null character (despite the POSIX +/// definition saying that NAME_MAX does not include the terminating null). +pub const NAME_MAX = 256; // limits.h pub const STDIN_FILENO = 0; pub const STDOUT_FILENO = 1; diff --git a/lib/std/fs.zig b/lib/std/fs.zig index c6b992a162..8dfd811930 100644 --- a/lib/std/fs.zig +++ b/lib/std/fs.zig @@ -48,19 +48,22 @@ pub const MAX_PATH_BYTES = switch (builtin.os.tag) { @compileError("PATH_MAX not implemented for " ++ @tagName(builtin.os.tag)), }; -/// This represents the maximum size of a UTF-8 encoded file name component that the -/// operating system will accept. All file name components returned by file system -/// operations are assumed to fit into a UTF-8 encoded array of this length. +/// This represents the maximum size of a UTF-8 encoded file name component that +/// the platform's common file systems support. File name components returned by file system +/// operations are likely to fit into a UTF-8 encoded array of this length, but +/// (depending on the platform) this assumption may not hold for every configuration. /// The byte count does not include a null sentinel byte. pub const MAX_NAME_BYTES = switch (builtin.os.tag) { - .linux, .macos, .ios, .freebsd, .dragonfly, .haiku => os.NAME_MAX, + .linux, .macos, .ios, .freebsd, .dragonfly => os.NAME_MAX, + // Haiku's NAME_MAX includes the null terminator, so subtract one. + .haiku => os.NAME_MAX - 1, .netbsd, .openbsd, .solaris => os.MAXNAMLEN, // Each UTF-16LE character may be expanded to 3 UTF-8 bytes. // If it would require 4 UTF-8 bytes, then there would be a surrogate // pair in the UTF-16LE, and we (over)account 3 bytes for it that way. .windows => os.windows.NAME_MAX * 3, // For WASI, the MAX_NAME will depend on the host OS, so it needs to be - // as large as the largest MAX_NAME_BYTES in order to work on any host OS. + // as large as the largest MAX_NAME_BYTES (Windows) in order to work on any host OS. // TODO determine if this is a reasonable approach .wasi => os.windows.NAME_MAX * 3, else => if (@hasDecl(root, "os") and @hasDecl(root.os, "NAME_MAX")) diff --git a/lib/std/fs/test.zig b/lib/std/fs/test.zig index f7159a835c..f6168054b6 100644 --- a/lib/std/fs/test.zig +++ b/lib/std/fs/test.zig @@ -726,7 +726,7 @@ fn testFilenameLimits(iterable_dir: IterableDir, maxed_filename: []const u8) !vo try iterable_dir.dir.deleteTree(maxed_filename); } -test "filename limits" { +test "max file name component lengths" { var tmp = tmpIterableDir(.{}); defer tmp.cleanup(); @@ -737,7 +737,8 @@ test "filename limits" { try testFilenameLimits(tmp.iterable_dir, &maxed_windows_filename); } else if (builtin.os.tag == .wasi) { // On WASI, the maxed filename depends on the host OS, so in order for this test to - // work on any host, we need to use a length that will work for all platforms. + // work on any host, we need to use a length that will work for all platforms + // (i.e. the minimum MAX_NAME_BYTES of all supported platforms). const maxed_wasi_filename = [_]u8{'1'} ** 255; try testFilenameLimits(tmp.iterable_dir, &maxed_wasi_filename); } else { diff --git a/lib/std/os/windows.zig b/lib/std/os/windows.zig index 7bed48a2bf..71dfc70d37 100644 --- a/lib/std/os/windows.zig +++ b/lib/std/os/windows.zig @@ -2981,6 +2981,18 @@ pub const PATH_MAX_WIDE = 32767; /// > lpMaximumComponentLength parameter of the GetVolumeInformation function /// > (this value is commonly 255 characters) /// from https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation +/// +/// > The value that is stored in the variable that *lpMaximumComponentLength points to is +/// > used to indicate that a specified file system supports long names. For example, for +/// > a FAT file system that supports long names, the function stores the value 255, rather +/// > than the previous 8.3 indicator. Long names can also be supported on systems that use +/// > the NTFS file system. +/// from https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationw +/// +/// The assumption being made here is that while lpMaximumComponentLength may vary, it will never +/// be larger than 255. +/// +/// TODO: More verification of this assumption. pub const NAME_MAX = 255; pub const FORMAT_MESSAGE_ALLOCATE_BUFFER = 0x00000100;