From: "MIYASHITA Hisashi" <himi@m17n.org>
Cc: knagano@sodan.org
Subject: Re: init_buffer PWD fix
Date: Tue, 23 Apr 2002 15:14:31 +0900 [thread overview]
Message-ID: <u662jvt4o.fsf@MILCH.meadowy.org> (raw)
In-Reply-To: <200204220618.g3M6Icg23696@sic.twinsun.com> (Paul Eggert's message of "Sun, 21 Apr 2002 23:18:38 -0700 (PDT)")
Primarily, I suggested this change to the ML, but I don't explain
the detail on that to Nagano-san. Sorry.
Paul Eggert <eggert@twinsun.com> writes:
>> From: Keiichiro Nagano (=?ISO-2022-JP?B?GyRCMUpMbjc9MGxPOhsoQg==?=) <knagano@sodan.org>
>> Date: Mon, 22 Apr 2002 05:15:17 +0900
>>
>> init_buffer uses environmental variable PWD to identify current
>> working directory. I think we should not use it on Windows. On
>> Windows with Cygwin, PWD is unreliable and confusing
>
> PWD is unreliable on all platforms, but Emacs works around the problem
> with a similar method on all platforms by statting $PWD and ".", and
> using $PWD only if stat results agree. What is the problem with
> this workaround on Windows?
Yes, the current Emacs implementation compares the result of stat("."), but
stat() of Windows could not strictly emulate the behavior especially on inode.
So if "PWD" environment variable is wrongly set, default_directory would be also
wrongly set.
But, in the first place, is this code necessary on all platform?
Even now, is it really efficient on almost all of the platforms?
I don't think we should stick to such hacked code for the simple
job to get the current directory.
FYI, I've tested the following code on Debian GNU/Linux (sid) to check
the efficiency.
----------------------------------------
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#define MAXPATHLEN 2048
#ifndef DIRECTORY_SEP
#define DIRECTORY_SEP '/'
#endif
#ifndef IS_DIRECTORY_SEP
#define IS_DIRECTORY_SEP(_c_) ((_c_) == DIRECTORY_SEP)
#endif
#ifndef IS_DEVICE_SEP
#ifndef DEVICE_SEP
#define IS_DEVICE_SEP(_c_) 0
#else
#define IS_DEVICE_SEP(_c_) ((_c_) == DEVICE_SEP)
#endif
#endif
char* getcwd_stat(char *buf)
{
char *pwd;
struct stat pwdstat, dotstat;
if ((pwd = getenv ("PWD")) != 0
&& (IS_DIRECTORY_SEP (*pwd) || (*pwd && IS_DEVICE_SEP (pwd[1])))
&& stat (pwd, &pwdstat) == 0
&& stat (".", &dotstat) == 0
&& dotstat.st_ino == pwdstat.st_ino
&& dotstat.st_dev == pwdstat.st_dev
&& strlen (pwd) < MAXPATHLEN)
strcpy (buf, pwd);
else
return NULL;
return buf;
}
char * getcwd_normal(char *buf)
{
return getcwd (buf, MAXPATHLEN + 1);
}
int main(int argc, char **argv)
{
char buf[MAXPATHLEN + 1];
char *pwd;
int i;
if (argv[1][0] == 's')
{
for (i = 0;i < 1000000;i++)
getcwd_stat(buf);
}
else
{
for (i = 0;i < 1000000;i++)
getcwd_normal(buf);
}
return 1;
}
----------------------------------------
The result are
[~:] time ./a.out s
./a.out s 1.22s user 2.68s system 100% cpu 3.883 total
[~:] time ./a.out n
./a.out n 0.29s user 0.92s system 100% cpu 1.200 total
----------------------------------------
Of course, this check only covers narrow situation. It may depends on
the file system the current directly locates. But at least, I could state
there exist situations that the hacked code is much slower than simple getcwd()
calling.
Therefore, I'd like to propose to remove this hacked optimization from init_buffer().
Do you have any comments?
With regards,
from himi
next prev parent reply other threads:[~2002-04-23 6:14 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-21 20:15 init_buffer PWD fix Keiichiro Nagano
2002-04-21 23:00 ` Keiichiro Nagano
2002-04-22 6:18 ` Paul Eggert
2002-04-22 7:20 ` Keiichiro Nagano
2002-04-22 11:15 ` Eli Zaretskii
2002-04-22 21:16 ` Jason Rumney
2002-04-22 7:53 ` Eli Zaretskii
2002-04-22 7:01 ` Paul Eggert
2002-04-22 8:10 ` Eli Zaretskii
2002-04-22 7:22 ` Paul Eggert
2002-04-22 11:14 ` Eli Zaretskii
2002-04-22 23:21 ` Paul Eggert
2002-04-23 6:05 ` Eli Zaretskii
2002-04-22 21:21 ` Jason Rumney
2002-04-23 5:56 ` Eli Zaretskii
2002-04-23 6:14 ` MIYASHITA Hisashi [this message]
2002-04-23 11:00 ` Eli Zaretskii
2002-04-24 17:55 ` Richard Stallman
2002-04-24 18:14 ` MIYASHITA Hisashi
2002-04-23 17:45 ` Paul Eggert
2002-04-24 6:52 ` MIYASHITA Hisashi
2002-04-24 7:13 ` Paul Eggert
2002-04-24 7:45 ` MIYASHITA Hisashi
2002-04-24 11:12 ` Eli Zaretskii
2002-04-24 10:30 ` MIYASHITA Hisashi
2002-04-24 16:03 ` Eli Zaretskii
2002-04-24 17:13 ` MIYASHITA Hisashi
2002-04-24 18:10 ` Eli Zaretskii
2002-04-24 18:25 ` MIYASHITA Hisashi
2002-04-24 19:19 ` Paul Eggert
2002-04-24 19:41 ` MIYASHITA Hisashi
2002-04-24 19:59 ` MIYASHITA Hisashi
2002-04-24 20:21 ` Paul Eggert
2002-04-24 20:41 ` MIYASHITA Hisashi
2002-04-24 21:01 ` Paul Eggert
2002-04-24 21:23 ` MIYASHITA Hisashi
2002-04-24 21:35 ` MIYASHITA Hisashi
2002-04-25 22:52 ` Stefan Monnier
2002-04-25 3:42 ` Eli Zaretskii
2002-04-24 16:47 ` Paul Eggert
2002-04-24 17:55 ` MIYASHITA Hisashi
2002-04-24 10:38 ` MIYASHITA Hisashi
2002-04-24 16:08 ` Eli Zaretskii
2002-04-24 16:10 ` Eli Zaretskii
2002-04-24 7:55 ` MIYASHITA Hisashi
2002-04-24 11:07 ` Eli Zaretskii
2002-04-24 11:05 ` Eli Zaretskii
2002-04-24 10:31 ` MIYASHITA Hisashi
2002-04-24 16:05 ` Eli Zaretskii
2002-04-22 7:03 ` Eli Zaretskii
2002-04-22 6:49 ` Keiichiro Nagano
2002-04-22 8:01 ` Eli Zaretskii
2002-04-22 8:26 ` Keiichiro Nagano
2002-04-22 11:19 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=u662jvt4o.fsf@MILCH.meadowy.org \
--to=himi@m17n.org \
--cc=knagano@sodan.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).