fs: Some NAME_MAX/MAX_NAME_BYTES improvements

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;

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"))

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 {

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;