GNU bug report logs - #13553
24.3.50; incorrect usage of IS_DIRECTORY_SEP

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#13553: closed (24.3.50; incorrect usage of IS_DIRECTORY_SEP)
Date: Sun, 27 Jan 2013 07:17:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 27 Jan 2013 09:15:45 +0200
with message-id <831ud7jdum.fsf <at> gnu.org>
and subject line Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP
has caused the debbugs.gnu.org bug report #13553,
regarding 24.3.50; incorrect usage of IS_DIRECTORY_SEP
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
13553: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13553
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; incorrect usage of IS_DIRECTORY_SEP
Date: Sat, 26 Jan 2013 14:52:59 +0900

Hi,

`file-attributes' returns nil as stat info for a file, its name ending
with a character whose second byte is 0x5c.

It is because IS_DIRECTORY_SEP is wrongly used.
IS_DIRECTORY_SEP only works when its argument is surely on a start
byte of dbcs characters.
I find incorrect usage, at least in some functions of `w32.c'.
(readdir, stat_worker, read_unc_volume)


I show, as a silly sample, of easy fix.

#define IS_AT_DIRECTORY_SEP(p,i) \
  (p[i] == '/' || (p[i] == '\\' && _mbsbtype(p,i) == _MBC_SINGLE))

and,

  IS_DIRECTORY_SEP(p[i]) 

to

  IS_AT_DIRECTORY_SEP(p, i) 


Regards,
Shigeru

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
Cc: 13553-done <at> debbugs.gnu.org
Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP
Date: Sun, 27 Jan 2013 09:15:45 +0200

> From: Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
> Cc: 13553 <at> debbugs.gnu.org
> Date: Sun, 27 Jan 2013 15:56:54 +0900
> 
> Built on migw32, and no trouble, thank you
> (I didn't do coverage tests, sorry).

Thanks.  I'm therefore closing this bug.

> But we must remember, my raise of issue is the incorrect usage of
> IS_DIRECTORY_SEP.  There are still more in fileio.c and more.

Yes.  This is being discussed on emacs-devel, and once that discussion
ends, the fileio.c and dired.c functions will be fixed as well.

> >> As for coding symbol, not a few Japanese use 'cp932 not 'shift-jis I 
> >> suppose.  But we need some notice for users.
> >
> >Not sure what you are saying here.  Do you think many Japanese Windows
> >users will set file-name-coding-system to shift_jis, or that most of
> >them will set it to cp932?
> >
> >Normally, users don't customize file-name-coding-system at all, in
> >which case Emacs will use default-file-name-coding-system, that is
> >automatically set to cp932, according to the system-wide codepage.
> 
> Yes, you are right. I mean, maybe, the case of using some remote file
> system.

Accessing remote files doesn't go through functions in w32.c, it goes
through file handlers (in Tramp).

> You can check by yourself their (our?) usage if you like.
> Some seems still using shift-jis, not cp932.
> 
> http://www.google.co.jp/search?q=file-name-coding-system+sjis

If they want 100% solid support, they will have to change their
customizations, sorry.  (We could implement an equivalence table,
whereby, e.g., shift_jis would be mapped to cp932, but these encodings
are slightly different, so I think that would be a kludge.)

In any case, the new code in w32.c is no worse than the previous one,
when file-name-coding-system is set to anything that is not a
recognized Windows codepage.  It is actually slightly better: it uses
the system-wide ANSI codepage in that case.  In most cases, this would
be the right thing anyway.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.