Re: [PATCH] Use FIX_UTF8_MAC to enable conversion from UTF8-MAC to UTF8

[Junio C Hamano <gitster@pobox.com>]

Mark Junker <mjscod@web.de> writes:

> diff --git a/compat/readdir.c b/compat/readdir.c
> new file mode 100644
> index 0000000..045cfef
> --- /dev/null
> +++ b/compat/readdir.c
> @@ -0,0 +1,26 @@
> +#include "../git-compat-util.h"
> +#include "../utf8.h"
> +
> +#undef readdir
> +
> +static struct dirent temp;
> +
> +struct dirent *gitreaddir(DIR *dirp)
> +{
> +	size_t utf8_len;
> +	char *utf8;
> +	struct dirent *result;
> +	result = readdir(dirp);
> +	if (result != NULL) {
> +		memcpy(&temp, result, sizeof(struct dirent));
> +		utf8 = reencode_string(temp.d_name, "UTF8", "UTF8-MAC");
> +		if (utf8 != NULL) {
> +			utf8_len = strlen(utf8);
> +			temp.d_namlen = (u_int8_t) utf8_len;
> +			memcpy(temp.d_name, utf8, utf8_len + 1);
> +			free(utf8);

I do not know how Macintosh libc implements "struc dirent", but
this approach does not work in general.  For example, on Linux
boxes with glibc, "struct dirent" is defined like this (pardon
the funny indentation --- that is from the original):

        struct dirent
          {
        #ifndef __USE_FILE_OFFSET64
            __ino_t d_ino;
            __off_t d_off;
        #else
            __ino64_t d_ino;
            __off64_t d_off;
        #endif
            unsigned short int d_reclen;
            unsigned char d_type;
            char d_name[256];		/* We must not include limits.h! */
          };

yet you can obtain a path component longer than 256 bytes.
Apparently the library allocates longer d_name[] field than what
is shown to the user.