Volume XXII, number 280Wednesday, October 7, 2026Latest message 51 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

patchprecompose_utf8: use a flex array for d_name

6 messages between Jul 3, 2026 and Jul 4, 2026, from Ihar Hrachyshka, Torsten Bögershausen, Junio C Hamano, Patrick Steinhardt.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Ihar HrachyshkaJul 3, 2026, 02:35 UTC on lore

On macOS, git status may abort while reading a directory entry whose UTF-8 name grows past NAME_MAX bytes:

  __chk_fail_overflow
  __strlcpy_chk
  precompose_utf8_readdir
  read_directory_recursive
  wt_status_collect
  cmd_status

The precompose wrapper already reallocates dirent_prec_psx for long names, but d_name is declared as char[NAME_MAX + 1]. A fortified libc can still see that declared object size and reject a larger strlcpy bound, even though the allocation was grown.

Make d_name a FLEX_ARRAY and size allocations from offsetof(). That matches the actual object layout with the dynamic allocation, so the fortified copy sees a destination whose size can grow with max_name_len.

Add a regression test that creates a 261-byte non-ASCII basename and runs status with core.precomposeunicode enabled.

Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
---
 compat/precompose_utf8.c     | 12 ++++++++----
 compat/precompose_utf8.h     |  9 +++++----
 t/t3910-mac-os-precompose.sh | 15 +++++++++++++++
 3 files changed, 28 insertions(+), 8 deletions(-)
Show changes to 3 files +28 −8

compat/precompose_utf8.c, compat/precompose_utf8.h, t/t3910-mac-os-precompose.sh

diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index 1711794..8077f62 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -19,6 +19,11 @@ typedef char *iconv_ibp;
 static const char *repo_encoding = "UTF-8";
 static const char *path_encoding = "UTF-8-MAC";
 
+static size_t dirent_prec_psx_size(size_t max_name_len)
+{
+	return st_add(offsetof(dirent_prec_psx, d_name), max_name_len);
+}
+
 static size_t has_non_ascii(const char *s, size_t maxlen, size_t *strlen_c)
 {
 	const uint8_t *ptr = (const uint8_t *)s;
@@ -114,8 +119,8 @@ const char *precompose_argv_prefix(int argc, const char **argv, const char *pref
 PREC_DIR *precompose_utf8_opendir(const char *dirname)
 {
 	PREC_DIR *prec_dir = xmalloc(sizeof(PREC_DIR));
-	prec_dir->dirent_nfc = xmalloc(sizeof(dirent_prec_psx));
-	prec_dir->dirent_nfc->max_name_len = sizeof(prec_dir->dirent_nfc->d_name);
+	prec_dir->dirent_nfc = xmalloc(dirent_prec_psx_size(NAME_MAX + 1));
+	prec_dir->dirent_nfc->max_name_len = NAME_MAX + 1;
 
 	prec_dir->dirp = opendir(dirname);
 	if (!prec_dir->dirp) {
@@ -145,8 +150,7 @@ struct dirent_prec_psx *precompose_utf8_readdir(PREC_DIR *prec_dir)
 		int ret_errno = errno;
 
 		if (new_maxlen > prec_dir->dirent_nfc->max_name_len) {
-			size_t new_len = sizeof(dirent_prec_psx) + new_maxlen -
-				sizeof(prec_dir->dirent_nfc->d_name);
+			size_t new_len = dirent_prec_psx_size(new_maxlen);
 
 			prec_dir->dirent_nfc = xrealloc(prec_dir->dirent_nfc, new_len);
 			prec_dir->dirent_nfc->max_name_len = new_maxlen;
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index fea06cf..c7c3cc2 100644
--- a/compat/precompose_utf8.h
+++ b/compat/precompose_utf8.h
@@ -14,11 +14,12 @@ typedef struct dirent_prec_psx {
 
 	/*
 	 * See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/dirent.h.html
-	 * NAME_MAX + 1 should be enough, but some systems have
-	 * NAME_MAX=255 and strlen(d_name) may return 508 or 510
-	 * Solution: allocate more when needed, see precompose_utf8_readdir()
+	 * Start with room for NAME_MAX + 1 bytes, but keep d_name as a
+	 * flexible array. Some systems have NAME_MAX=255 while strlen(d_name)
+	 * from readdir() may return 508 or 510 bytes. Grow the allocation as
+	 * needed in precompose_utf8_readdir().
 	 */
-	char   d_name[NAME_MAX+1];
+	char   d_name[FLEX_ARRAY];
 } dirent_prec_psx;
 
 
diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh
index 6d5918c..fda4a76 100755
--- a/t/t3910-mac-os-precompose.sh
+++ b/t/t3910-mac-os-precompose.sh
@@ -207,6 +207,21 @@ test_expect_success "Add long precomposed filename" '
 	git commit -m "Long filename"
 '
 
+test_expect_success "status with long non-ASCII filename" '
+	test_when_finished "rm -rf long-utf8-status" &&
+	git init long-utf8-status &&
+	(
+		cd long-utf8-status &&
+		test "$(git config --bool core.precomposeunicode)" = true &&
+		long_utf8_name=$(
+			perl -e "print q(a) x 249, qq(\342\200\224) x 3, q(.md)"
+		) &&
+		test "$(printf "%s" "$long_utf8_name" | wc -c | tr -d " ")" = 261 &&
+		printf "content\n" >"$long_utf8_name" &&
+		git status --porcelain=v1 >actual
+	)
+'
+
 test_expect_failure 'handle existing decomposed filenames' '
 	echo content >"verbatim.$Adiarnfd" &&
 	git -c core.precomposeunicode=false add "verbatim.$Adiarnfd" &&

base-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc
-- 
2.54.0
Torsten BögershausenJul 3, 2026, 05:08 UTC in reply to Ihar Hrachyshka on lore

Re: [PATCH] precompose_utf8: use a flex array for d_name

On Thu, Jul 02, 2026 at 10:35:54PM -0400, Ihar Hrachyshka wrote:
Show 23 quoted lines
> On macOS, git status may abort while reading a directory entry
> whose UTF-8 name grows past NAME_MAX bytes:
> 
>   __chk_fail_overflow
>   __strlcpy_chk
>   precompose_utf8_readdir
>   read_directory_recursive
>   wt_status_collect
>   cmd_status
> 
> The precompose wrapper already reallocates dirent_prec_psx for
> long names, but d_name is declared as char[NAME_MAX + 1]. A
> fortified libc can still see that declared object size and reject a
> larger strlcpy bound, even though the allocation was grown.
> 
> Make d_name a FLEX_ARRAY and size allocations from offsetof(). That
> matches the actual object layout with the dynamic allocation, so the
> fortified copy sees a destination whose size can grow with max_name_len.
> 
> Add a regression test that creates a 261-byte non-ASCII basename and
> runs status with core.precomposeunicode enabled.
> 
> Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>

Nice, thanks for the patch. One minor nit/question: Do we need a test_have_prereq PERL in t/t3910 ?

[]
Show 27 quoted lines
> diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh
> index 6d5918c..fda4a76 100755
> --- a/t/t3910-mac-os-precompose.sh
> +++ b/t/t3910-mac-os-precompose.sh
> @@ -207,6 +207,21 @@ test_expect_success "Add long precomposed filename" '
>  	git commit -m "Long filename"
>  '
>  
> +test_expect_success "status with long non-ASCII filename" '
> +	test_when_finished "rm -rf long-utf8-status" &&
> +	git init long-utf8-status &&
> +	(
> +		cd long-utf8-status &&
> +		test "$(git config --bool core.precomposeunicode)" = true &&
> +		long_utf8_name=$(
> +			perl -e "print q(a) x 249, qq(\342\200\224) x 3, q(.md)"
> +		) &&
> +		test "$(printf "%s" "$long_utf8_name" | wc -c | tr -d " ")" = 261 &&
> +		printf "content\n" >"$long_utf8_name" &&
> +		git status --porcelain=v1 >actual
> +	)
> +'
> +
>  test_expect_failure 'handle existing decomposed filenames' '
>  	echo content >"verbatim.$Adiarnfd" &&
>  	git -c core.precomposeunicode=false add "verbatim.$Adiarnfd" &&
> 
Junio C HamanoJul 3, 2026, 08:39 UTC in reply to Torsten Bögershausen on lore

Re: [PATCH] precompose_utf8: use a flex array for d_name

Torsten Bögershausen <tboegi@web.de> writes:
> Nice, thanks for the patch.  One minor nit/question: Do we need a
> test_have_prereq PERL in t/t3910 ?
Good question.
Show 11 quoted lines
>> +test_expect_success "status with long non-ASCII filename" '
>> +	test_when_finished "rm -rf long-utf8-status" &&
>> +	git init long-utf8-status &&
>> +	(
>> +		cd long-utf8-status &&
>> +		test "$(git config --bool core.precomposeunicode)" = true &&
>> +		long_utf8_name=$(
>> +			perl -e "print q(a) x 249, qq(\342\200\224) x 3, q(.md)"
>> +		) &&
>> +		test "$(printf "%s" "$long_utf8_name" | wc -c | tr -d " ")" = 261 &&
>> +		printf "content\n" >"$long_utf8_name" &&

I would say that if we are going to use this construct as-is, then we do need the prereq.

But as far as I can see, this is mostly to create a very long filename, which does not require perl at all, with 9 bytes of binary which could be easily done with printf with the ame backslash notation.

So, if we can fix the test, that would be preferrable.
Thanks.
Show 8 quoted lines
>> +		git status --porcelain=v1 >actual
>> +	)
>> +'
>> +
>>  test_expect_failure 'handle existing decomposed filenames' '
>>  	echo content >"verbatim.$Adiarnfd" &&
>>  	git -c core.precomposeunicode=false add "verbatim.$Adiarnfd" &&
>> 
Patrick SteinhardtJul 3, 2026, 08:40 UTC in reply to Ihar Hrachyshka on lore

Re: [PATCH] precompose_utf8: use a flex array for d_name

On Thu, Jul 02, 2026 at 10:35:54PM -0400, Ihar Hrachyshka wrote:
Show 21 quoted lines
> On macOS, git status may abort while reading a directory entry
> whose UTF-8 name grows past NAME_MAX bytes:
> 
>   __chk_fail_overflow
>   __strlcpy_chk
>   precompose_utf8_readdir
>   read_directory_recursive
>   wt_status_collect
>   cmd_status
> 
> The precompose wrapper already reallocates dirent_prec_psx for
> long names, but d_name is declared as char[NAME_MAX + 1]. A
> fortified libc can still see that declared object size and reject a
> larger strlcpy bound, even though the allocation was grown.
> 
> Make d_name a FLEX_ARRAY and size allocations from offsetof(). That
> matches the actual object layout with the dynamic allocation, so the
> fortified copy sees a destination whose size can grow with max_name_len.
> 
> Add a regression test that creates a 261-byte non-ASCII basename and
> runs status with core.precomposeunicode enabled.

Hm. Why does macOS even allow you to create a file that has a basename longer than NAME_MAX? Does macOS count unicode characters specially?

Show 24 quoted lines
> diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
> index 1711794..8077f62 100644
> --- a/compat/precompose_utf8.c
> +++ b/compat/precompose_utf8.c
> @@ -19,6 +19,11 @@ typedef char *iconv_ibp;
>  static const char *repo_encoding = "UTF-8";
>  static const char *path_encoding = "UTF-8-MAC";
>  
> +static size_t dirent_prec_psx_size(size_t max_name_len)
> +{
> +	return st_add(offsetof(dirent_prec_psx, d_name), max_name_len);
> +}
> +
>  static size_t has_non_ascii(const char *s, size_t maxlen, size_t *strlen_c)
>  {
>  	const uint8_t *ptr = (const uint8_t *)s;
> @@ -114,8 +119,8 @@ const char *precompose_argv_prefix(int argc, const char **argv, const char *pref
>  PREC_DIR *precompose_utf8_opendir(const char *dirname)
>  {
>  	PREC_DIR *prec_dir = xmalloc(sizeof(PREC_DIR));
> -	prec_dir->dirent_nfc = xmalloc(sizeof(dirent_prec_psx));
> -	prec_dir->dirent_nfc->max_name_len = sizeof(prec_dir->dirent_nfc->d_name);
> +	prec_dir->dirent_nfc = xmalloc(dirent_prec_psx_size(NAME_MAX + 1));
> +	prec_dir->dirent_nfc->max_name_len = NAME_MAX + 1;

We have the `FLEX_ALLOC_MEM()` macro that would probably be a better fit compared to introducing `dirent_prec_psx_size()`.

Also, when converting this to a flex array, can't we do better here and allocate the structures with the right size? Otherwise, I expect that we overallocate most of the entrise.

Show 10 quoted lines
> @@ -145,8 +150,7 @@ struct dirent_prec_psx *precompose_utf8_readdir(PREC_DIR *prec_dir)
>  		int ret_errno = errno;
>  
>  		if (new_maxlen > prec_dir->dirent_nfc->max_name_len) {
> -			size_t new_len = sizeof(dirent_prec_psx) + new_maxlen -
> -				sizeof(prec_dir->dirent_nfc->d_name);
> +			size_t new_len = dirent_prec_psx_size(new_maxlen);
>  
>  			prec_dir->dirent_nfc = xrealloc(prec_dir->dirent_nfc, new_len);
>  			prec_dir->dirent_nfc->max_name_len = new_maxlen;

Okay, here we indeed have to realloc though, and thus we can't quite avoid `dirent_prec_psx_size()`. Too bad.

Thanks!
Patrick
Ihar HrachyshkaJul 3, 2026, 20:20 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] precompose_utf8: use a flex array for d_name

On 7/3/26 4:40 AM, Patrick Steinhardt wrote:
Show 24 quoted lines
> On Thu, Jul 02, 2026 at 10:35:54PM -0400, Ihar Hrachyshka wrote:
>> On macOS, git status may abort while reading a directory entry
>> whose UTF-8 name grows past NAME_MAX bytes:
>>
>>    __chk_fail_overflow
>>    __strlcpy_chk
>>    precompose_utf8_readdir
>>    read_directory_recursive
>>    wt_status_collect
>>    cmd_status
>>
>> The precompose wrapper already reallocates dirent_prec_psx for
>> long names, but d_name is declared as char[NAME_MAX + 1]. A
>> fortified libc can still see that declared object size and reject a
>> larger strlcpy bound, even though the allocation was grown.
>>
>> Make d_name a FLEX_ARRAY and size allocations from offsetof(). That
>> matches the actual object layout with the dynamic allocation, so the
>> fortified copy sees a destination whose size can grow with max_name_len.
>>
>> Add a regression test that creates a 261-byte non-ASCII basename and
>> runs status with core.precomposeunicode enabled.
> Hm. Why does macOS even allow you to create a file that has a basename
> longer than NAME_MAX? Does macOS count unicode characters specially?

Yes, macOS file names can exceed NAME_MAX bytes because the real dirent limit in system headers is:

#define __DARWIN_MAXPATHLEN 1024

#define __DARWIN_STRUCT_DIRENTRY { \ char d_name[__DARWIN_MAXPATHLEN]; /* entry name (up to MAXPATHLEN bytes) */ \ }

(for a very old 32-bit ABI it's 256 but it's not really relevant)

This in-memory limit may be further capped by file system. For HFS+, it's 255 16-bit Unicode characters (as per on-disk format). For APFS, on-disk theoretically allows up to 1022 UTF-8 bytes, but my testing suggests they still enforce the same 255 character limit somewhere in kernel API layer. (Which means that they could later expand the maximum filename length further without changing the on-disk format.)

So effectively, today on Darwin, the real limit is "up to 255 2-byte code points", not bytes. Which is potentially beyond NAME_MAX.

...that said, Linux readdir() doesn't guarantee NAME_MAX limit either. 
 From readdir(3):
"""
         Note that while the call
             fpathconf(fd, _PC_NAME_MAX)
         returns the value 255 for most filesystems, on some filesystems
         (e.g., CIFS, Windows SMB servers), the null-terminated filename
         that is (correctly) returned in .d_name can actually exceed this
         size.  In such cases, the .d_reclen field will contain a value
         that exceeds the size of the glibc dirent structure shown above.
"""

The man page also advises against using sizeof() against dirent structs. (Which is what we currently do - against our own MacOS helper dirent struct.)

As a side note, it probably means neither Darwin nor Linux readdir() is POSIX compliant, because, as per:

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/dirent.h.html

"The array d_name in each of these structures is of unspecified size, but shall contain a filename of at most {NAME_MAX} bytes followed by a terminating null byte."

Show 30 quoted lines
>> diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
>> index 1711794..8077f62 100644
>> --- a/compat/precompose_utf8.c
>> +++ b/compat/precompose_utf8.c
>> @@ -19,6 +19,11 @@ typedef char *iconv_ibp;
>>   static const char *repo_encoding = "UTF-8";
>>   static const char *path_encoding = "UTF-8-MAC";
>>   
>> +static size_t dirent_prec_psx_size(size_t max_name_len)
>> +{
>> +	return st_add(offsetof(dirent_prec_psx, d_name), max_name_len);
>> +}
>> +
>>   static size_t has_non_ascii(const char *s, size_t maxlen, size_t *strlen_c)
>>   {
>>   	const uint8_t *ptr = (const uint8_t *)s;
>> @@ -114,8 +119,8 @@ const char *precompose_argv_prefix(int argc, const char **argv, const char *pref
>>   PREC_DIR *precompose_utf8_opendir(const char *dirname)
>>   {
>>   	PREC_DIR *prec_dir = xmalloc(sizeof(PREC_DIR));
>> -	prec_dir->dirent_nfc = xmalloc(sizeof(dirent_prec_psx));
>> -	prec_dir->dirent_nfc->max_name_len = sizeof(prec_dir->dirent_nfc->d_name);
>> +	prec_dir->dirent_nfc = xmalloc(dirent_prec_psx_size(NAME_MAX + 1));
>> +	prec_dir->dirent_nfc->max_name_len = NAME_MAX + 1;
> We have the `FLEX_ALLOC_MEM()` macro that would probably be a better fit
> compared to introducing `dirent_prec_psx_size()`.
>
> Also, when converting this to a flex array, can't we do better here and
> allocate the structures with the right size? Otherwise, I expect that we
> overallocate most of the entrise.

As I understand it, this is a *per-directory* buffer that starts from NAME_MAX + 1, then gets expanded as entries with names longer than NAME_MAX + 1 are encountered. It is reused for next entries.

Show 16 quoted lines
>> @@ -145,8 +150,7 @@ struct dirent_prec_psx *precompose_utf8_readdir(PREC_DIR *prec_dir)
>>   		int ret_errno = errno;
>>   
>>   		if (new_maxlen > prec_dir->dirent_nfc->max_name_len) {
>> -			size_t new_len = sizeof(dirent_prec_psx) + new_maxlen -
>> -				sizeof(prec_dir->dirent_nfc->d_name);
>> +			size_t new_len = dirent_prec_psx_size(new_maxlen);
>>   
>>   			prec_dir->dirent_nfc = xrealloc(prec_dir->dirent_nfc, new_len);
>>   			prec_dir->dirent_nfc->max_name_len = new_maxlen;
> Okay, here we indeed have to realloc though, and thus we can't quite
> avoid `dirent_prec_psx_size()`. Too bad.
>
> Thanks!
>
> Patrick
Ihar HrachyshkaJul 4, 2026, 23:37 UTC in reply to Ihar Hrachyshka on lore

[PATCH v2] precompose_utf8: use a flex array for d_name

On macOS, git status may abort while reading a directory entry whose UTF-8 name grows past NAME_MAX bytes:

  __chk_fail_overflow
  __strlcpy_chk
  precompose_utf8_readdir
  read_directory_recursive
  wt_status_collect
  cmd_status

The precompose wrapper already reallocates dirent_prec_psx for long names, but d_name is declared as char[NAME_MAX + 1]. A fortified libc can still see that declared object size and reject a larger strlcpy bound, even though the allocation was grown.

Make d_name a FLEX_ARRAY and size allocations from offsetof(). That matches the actual object layout with the dynamic allocation, so the fortified copy sees a destination whose size can grow with max_name_len.

Add a regression test that creates an over-NAME_MAX non-ASCII basename and runs status with core.precomposeunicode enabled.

Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
---
Changes in v2:
- Drop perl from the regression test and use printf/tr instead.
- Use the minimal 256-byte filename that reproduces the crash.
 compat/precompose_utf8.c     | 12 ++++++++----
 compat/precompose_utf8.h     |  9 +++++----
 t/t3910-mac-os-precompose.sh | 16 ++++++++++++++++
 3 files changed, 29 insertions(+), 8 deletions(-)
Show changes to 3 files +29 −8

compat/precompose_utf8.c, compat/precompose_utf8.h, t/t3910-mac-os-precompose.sh

diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index 1711794..8077f62 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -19,6 +19,11 @@ typedef char *iconv_ibp;
 static const char *repo_encoding = "UTF-8";
 static const char *path_encoding = "UTF-8-MAC";
 
+static size_t dirent_prec_psx_size(size_t max_name_len)
+{
+	return st_add(offsetof(dirent_prec_psx, d_name), max_name_len);
+}
+
 static size_t has_non_ascii(const char *s, size_t maxlen, size_t *strlen_c)
 {
 	const uint8_t *ptr = (const uint8_t *)s;
@@ -114,8 +119,8 @@ const char *precompose_argv_prefix(int argc, const char **argv, const char *pref
 PREC_DIR *precompose_utf8_opendir(const char *dirname)
 {
 	PREC_DIR *prec_dir = xmalloc(sizeof(PREC_DIR));
-	prec_dir->dirent_nfc = xmalloc(sizeof(dirent_prec_psx));
-	prec_dir->dirent_nfc->max_name_len = sizeof(prec_dir->dirent_nfc->d_name);
+	prec_dir->dirent_nfc = xmalloc(dirent_prec_psx_size(NAME_MAX + 1));
+	prec_dir->dirent_nfc->max_name_len = NAME_MAX + 1;
 
 	prec_dir->dirp = opendir(dirname);
 	if (!prec_dir->dirp) {
@@ -145,8 +150,7 @@ struct dirent_prec_psx *precompose_utf8_readdir(PREC_DIR *prec_dir)
 		int ret_errno = errno;
 
 		if (new_maxlen > prec_dir->dirent_nfc->max_name_len) {
-			size_t new_len = sizeof(dirent_prec_psx) + new_maxlen -
-				sizeof(prec_dir->dirent_nfc->d_name);
+			size_t new_len = dirent_prec_psx_size(new_maxlen);
 
 			prec_dir->dirent_nfc = xrealloc(prec_dir->dirent_nfc, new_len);
 			prec_dir->dirent_nfc->max_name_len = new_maxlen;
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index fea06cf..c7c3cc2 100644
--- a/compat/precompose_utf8.h
+++ b/compat/precompose_utf8.h
@@ -14,11 +14,12 @@ typedef struct dirent_prec_psx {
 
 	/*
 	 * See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/dirent.h.html
-	 * NAME_MAX + 1 should be enough, but some systems have
-	 * NAME_MAX=255 and strlen(d_name) may return 508 or 510
-	 * Solution: allocate more when needed, see precompose_utf8_readdir()
+	 * Start with room for NAME_MAX + 1 bytes, but keep d_name as a
+	 * flexible array. Some systems have NAME_MAX=255 while strlen(d_name)
+	 * from readdir() may return 508 or 510 bytes. Grow the allocation as
+	 * needed in precompose_utf8_readdir().
 	 */
-	char   d_name[NAME_MAX+1];
+	char   d_name[FLEX_ARRAY];
 } dirent_prec_psx;
 
 
diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh
index 6d5918c..ea75fb4 100755
--- a/t/t3910-mac-os-precompose.sh
+++ b/t/t3910-mac-os-precompose.sh
@@ -207,6 +207,22 @@ test_expect_success "Add long precomposed filename" '
 	git commit -m "Long filename"
 '
 
+test_expect_success "status with long non-ASCII filename" '
+	test_when_finished "rm -rf long-utf8-status" &&
+	git init long-utf8-status &&
+	(
+		cd long-utf8-status &&
+		test "$(git config --bool core.precomposeunicode)" = true &&
+		long_utf8_name=$(
+			printf "%253s\342\200\224" "" |
+			tr " " a
+		) &&
+		test "$(printf "%s" "$long_utf8_name" | wc -c | tr -d " ")" = 256 &&
+		printf "content\n" >"$long_utf8_name" &&
+		git status --porcelain=v1 >actual
+	)
+'
+
 test_expect_failure 'handle existing decomposed filenames' '
 	echo content >"verbatim.$Adiarnfd" &&
 	git -c core.precomposeunicode=false add "verbatim.$Adiarnfd" &&
-- 
2.54.0

Back to recent threads