unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

  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).