Re: fun with dired sorting

[Andrew Innes]

On 03 Jan 2001 23:14:44 +0000, Andrew Innes <address@hidden> said:
>On 08 Dec 2000 11:51:59 +0000, Andrew Innes <address@hidden> said:
>>Actually, it looks like some implicit interpretation of the bytes
>>returned by the OS takes place first, when Emacs converts the filename
>>returned by readdir to a lisp string.  In particular, that conversion to
>>a string may decide some of the bytes should be interpreted as multibyte
>>characters (using the internal Emacs encoding).
>>
>>I think that is wrong.  I believe the raw bytes returned by readdir
>>should be directly decoded using `file-name-coding-system'.
>
>I didn't hear any comment on the above, so I'm wondering if I should
>install a change that creates a unibyte lisp string from the readdir
>result, so that the subsequent invocation of DECODE_FILE is working from
>the right data.
>
>Any objections?
>
>AndrewI

I assume there are no objections, so I've installed the following
change.

AndrewI

2001-01-17  Andrew Innes  <address@hidden>

        * dired.c (directory_files_internal): Convert result from readdir
        to a unibyte string initially, to avoid possible misinterpretation
        of some bytes as the internal form of Emacs characters.

RCS file: /cvs/emacs/src/dired.c,v
retrieving revision 1.80
retrieving revision 1.81
diff -c -b -c -r1.80 -r1.81
*** dired.c     2001/01/03 12:43:54     1.80
--- dired.c     2001/01/17 11:11:06     1.81
***************
*** 218,224 ****
          struct gcpro gcpro1, gcpro2;
  
          len = NAMLEN (dp);
!         name = finalname = make_string (dp->d_name, len);
          GCPRO2 (finalname, name);
          
          /* Note: ENCODE_FILE can GC; it should protect its argument,
--- 218,224 ----
          struct gcpro gcpro1, gcpro2;
  
          len = NAMLEN (dp);
!         name = finalname = make_unibyte_string (dp->d_name, len);
          GCPRO2 (finalname, name);
          
          /* Note: ENCODE_FILE can GC; it should protect its argument,