emacs & MAXPATHLEN

emacs & MAXPATHLEN

[Giuseppe Scrivano]

Hi,
Shouldn't the MAXPATHLEN present in the emacs source code be removed to avoid incompatibilities with hurd?

Regards,
Giuseppe Scrivano

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    Shouldn't the MAXPATHLEN present in the emacs source code be
    removed to avoid incompatibilities with hurd?

Yes.  And we want to get rid of arbitrary limits anyway.

I found only one place where MAXPATHLEN is used,
aside from conditionals for specific proprietary systems.
That is in init_buffer.  Would someone like to convert it
to extend its buffer when needed?

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Shouldn't the MAXPATHLEN present in the emacs source code be
>     removed to avoid incompatibilities with hurd?
>
> Yes.  And we want to get rid of arbitrary limits anyway.
>
> I found only one place where MAXPATHLEN is used,
> aside from conditionals for specific proprietary systems.
> That is in init_buffer.  Would someone like to convert it
> to extend its buffer when needed?
Hi,
This little patch should fix it. If something is wrong comments are well accepted.

--- src/buffer.c.old    2005-07-28 19:14:42.000000000 +0200
+++ src/buffer.c        2005-07-29 02:21:03.000000000 +0200
@@ -5114,7 +5114,7 @@
 void
 init_buffer ()
 {
-  char buf[MAXPATHLEN + 1];
+  char *buf;
   char *pwd;
   struct stat dotstat, pwdstat;
   Lisp_Object temp;
@@ -5146,14 +5146,47 @@
       && stat (".", &dotstat) == 0
       && dotstat.st_ino == pwdstat.st_ino
       && dotstat.st_dev == pwdstat.st_dev
-      && strlen (pwd) < MAXPATHLEN)
-    strcpy (buf, pwd);
-#ifdef HAVE_GETCWD
-  else if (getcwd (buf, MAXPATHLEN+1) == 0)
-    fatal ("`getcwd' failed: %s\n", strerror (errno));
+#ifdef MAXPATHLEN
+      && strlen (pwd) < MAXPATHLEN
+#endif
+      )
+    {
+      buf = malloc(strlen(pwd)+1);
+      if(!buf)
+        fatal ("`malloc' failed in init_buffer\n");
+      strcpy (buf, pwd);
+    }
+#ifdef _GNU_SOURCE
+  else
+    {
+      buf = get_current_dir_name();
+      if(!buf)
+        fatal ("`get_current_dir_name' failed in init_buffer\n");
+    }
+#elif HAVE_GETCWD
+  else
+    {
+      buf = malloc(MAXPATHLEN+1);
+      if(!buf)
+        fatal ("`malloc' failed in init_buffer\n");
+      if(buf)
+        {
+          if(getcdwd (buf, MAXPATHLEN+1) == 0)
+            fatal ("`getwd' failed: %s\n", buf);
+        }
+    }
 #else
-  else if (getwd (buf) == 0)
-    fatal ("`getwd' failed: %s\n", buf);
+  else
+    {
+      buf = malloc(MAXPATHLEN+1);
+      if(!buf)
+        fatal ("`malloc' failed in init_buffer\n");
+      if(buf)
+        {
+          if(getwd (buf) == 0)
+            fatal ("`getwd' failed: %s\n", buf);
+        }
+    }
 #endif

 #ifndef VMS
@@ -5189,6 +5222,7 @@

   temp = get_minibuffer (0);
   XBUFFER (temp)->directory = current_buffer->directory;
+  free(buf);
 }

 /* initialize the buffer routines */



I worked on the xsmfns.c file too. I am not sure if this is required for the hurd compatibility.  


--- src/xsmfns.c.old    2005-07-28 19:51:24.000000000 +0200
+++ src/xsmfns.c        2005-07-28 21:30:11.000000000 +0200
@@ -56,7 +56,6 @@
 #define MAXPATHLEN 1024
 #endif /* not MAXPATHLEN */

-
 /* The user login name.  */

 extern Lisp_Object Vuser_login_name;
@@ -205,7 +204,7 @@
   int val_idx = 0;
   int props_idx = 0;

-  char cwd[MAXPATHLEN+1];
+  char *cwd = NULL;
   char *smid_opt;

   /* How to start a new instance of Emacs.  */
@@ -259,12 +258,28 @@
   props[props_idx]->vals[0].value = SDATA (Vuser_login_name);
   ++props_idx;

-  /* The current directory property, not mandatory.  */
-#ifdef HAVE_GETCWD
-  if (getcwd (cwd, MAXPATHLEN+1) != 0)
+#ifdef _GNU_SOURCE
+  cwd = get_current_dir_name();
+  if(!cwd)
+    fatal ("`get_current_dir_name' failed in smc_save_yourself_CB\n");
+#elif HAVE_GETCWD
+  cwd = malloc(MAXPATHLEN+1);
+  if(!cwd)
+    fatal ("`malloc' failed in failed in smc_save_yourself_CB\n");
+  if(cwd)
+    {
+      if(getcdwd (cwd, MAXPATHLEN+1) == 0)
+        fatal ("`getwd' failed: %s\n", cwd);
+    }
 #else
-  if (getwd (cwd) != 0)
+  cwd = malloc(MAXPATHLEN+1);
+  if(!cwd)
+    fatal ("`malloc' failed in smc_save_yourself_CB\n");
+  if(getwd (cwd) == 0)
+    fatal ("`getwd' failed: %s\n", cwd);
 #endif
+
+  if(!cwd)
     {
       props[props_idx] = &prop_ptr[props_idx];
       props[props_idx]->name = SmCurrentDirectory;
@@ -280,6 +295,7 @@
   SmcSetProperties (smcConn, props_idx, props);

   xfree (smid_opt);
+  free(cwd);

   /* See if we maybe shall interact with the user.  */
   if (interactStyle != SmInteractStyleAny


Regards,
Giuseppe Scrivano

Re: emacs & MAXPATHLEN

[Alfred M. Szmidt]

   --- src/buffer.c.old    2005-07-28 19:14:42.000000000 +0200
   +++ src/buffer.c        2005-07-29 02:21:03.000000000 +0200
   @@ -5146,14 +5146,47 @@
	  && stat (".", &dotstat) == 0
	  && dotstat.st_ino == pwdstat.st_ino
	  && dotstat.st_dev == pwdstat.st_dev
   -      && strlen (pwd) < MAXPATHLEN)
   -    strcpy (buf, pwd);
   -#ifdef HAVE_GETCWD
   -  else if (getcwd (buf, MAXPATHLEN+1) == 0)
   -    fatal ("`getcwd' failed: %s\n", strerror (errno));
   +#ifdef MAXPATHLEN
   +      && strlen (pwd) < MAXPATHLEN
   +#endif
   +      )
   +    {
   +      buf = malloc(strlen(pwd)+1);
   +      if(!buf)
   +        fatal ("`malloc' failed in init_buffer\n");
   +      strcpy (buf, pwd);
   +    }
   +#ifdef _GNU_SOURCE

Using _GNU_SOURCE is always wrong, you should check for the feature
(in this case, get_current_dir_name ()).  That way, any system that
implements get_current_dir_name will be free from the MAXPATHLEN
limit.

Oh, and you should follow the GNU Coding Standard when it comes to
indenting.

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

You're right that xsmfns.c needs to be fixed too.  I overlooked that
one.


    +#ifdef _GNU_SOURCE

The purpose of _GNU_SOURCE is to control the behavior of
system header files.  User programs should not test it, only set it.
We could have config test for the existence of get_current_dir_name.

+      buf = malloc(strlen(pwd)+1);
+      if(!buf)
+        fatal ("`malloc' failed in init_buffer\n");

Our convention for whitespace is

+      buf = malloc (strlen (pwd)+1);
+      if (!buf)
+        fatal ("`malloc' failed in init_buffer\n");

However, the main thing is that you haven't got rid of the
arbitrary limit.  You allocate the buffer dynamically,
but you don't make it bigger if the data doesn't fit.

Re: emacs & MAXPATHLEN

[Eli Zaretskii]

> From: Giuseppe Scrivano <gscrivano@gmail.com>
> Date: Fri, 29 Jul 2005 02:22:37 +0200
> Cc: emacs-devel@gnu.org
> 
> This little patch should fix it.

Thanks, but please see my comments below.

> @@ -5146,14 +5146,47 @@
>        && stat (".", &dotstat) == 0
>        && dotstat.st_ino == pwdstat.st_ino
>        && dotstat.st_dev == pwdstat.st_dev
> -      && strlen (pwd) < MAXPATHLEN)
> -    strcpy (buf, pwd);
> -#ifdef HAVE_GETCWD
> -  else if (getcwd (buf, MAXPATHLEN+1) == 0)
> -    fatal ("`getcwd' failed: %s\n", strerror (errno));
> +#ifdef MAXPATHLEN
> +      && strlen (pwd) < MAXPATHLEN
> +#endif
> +      )
> +    {
> +      buf = malloc(strlen(pwd)+1);
> +      if(!buf)
> +        fatal ("`malloc' failed in init_buffer\n");

This should have used xmalloc instead of calling malloc and checking
for errors.

> +#ifdef _GNU_SOURCE
> +  else
> +    {
> +      buf = get_current_dir_name();
> +      if(!buf)
> +        fatal ("`get_current_dir_name' failed in init_buffer\n");
> +    }

I think this part is unnecessary.  The old code didn't use
get_current_dir_name, so I think we should not introduce it now.

In any case, if we do introduce get_current_dir_name, we should add an
Autoconf test for it, and then use HAVE_GET_CURRENT_DIR instead of
_GNU_SOURCE (which I think is the wrong test anyway, btw: _GNU_SOURCE
has nothing to do with availability of certain library functions).

> +          if(getcdwd (buf, MAXPATHLEN+1) == 0)
                ^^^^^^^
There's a typo in this line.  Did you check that all the branches
actually compile?

> +  else
> +    {
> +      buf = malloc(MAXPATHLEN+1);

You are using MAXPATHLEN without testing for it being defined.  If it
is okay to assume that it is always defined, then why you introduced a
test for that in the first hunk of your changes (see above)?

> +      if(!buf)
> +        fatal ("`malloc' failed in init_buffer\n");

Again, please use xmalloc.

> +      buf = malloc(MAXPATHLEN+1);
> +      if(!buf)
> +        fatal ("`malloc' failed in init_buffer\n");
> +      if(buf)
> +        {
> +          if(getwd (buf) == 0)
> +            fatal ("`getwd' failed: %s\n", buf);
> +        }

And here too: please use xmalloc, and please resolve the MAXPATHLEN
issue.

> +    }
>  #endif
> 
>  #ifndef VMS
> @@ -5189,6 +5222,7 @@
> 
>    temp = get_minibuffer (0);
>    XBUFFER (temp)->directory = current_buffer->directory;
> +  free(buf);
>  }
> 
>  /* initialize the buffer routines */
> 
> 
> 
> I worked on the xsmfns.c file too. I am not sure if this is required for the hurd compatibility.  

The same comments apply there as well.

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

"Richard M. Stallman" <rms@gnu.org> writes:
OK, I will fix that errors and make the getcwd code allocated dynamically.

Giuseppe Scrivano
> You're right that xsmfns.c needs to be fixed too.  I overlooked that
> one.
>
>
>     +#ifdef _GNU_SOURCE
>
> The purpose of _GNU_SOURCE is to control the behavior of
> system header files.  User programs should not test it, only set it.
> We could have config test for the existence of get_current_dir_name.
>
> +      buf = malloc(strlen(pwd)+1);
> +      if(!buf)
> +        fatal ("`malloc' failed in init_buffer\n");
>
> Our convention for whitespace is
>
> +      buf = malloc (strlen (pwd)+1);
> +      if (!buf)
> +        fatal ("`malloc' failed in init_buffer\n");
>
> However, the main thing is that you haven't got rid of the
> arbitrary limit.  You allocate the buffer dynamically,
> but you don't make it bigger if the data doesn't fit.

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

This new patch should fix the problem both with get_current_dir_name and getcwd. I think a compilation error when getwd is used without a MAXPATHLEN is nice to have.
The buffer used with getcwd is duplicated ever time it is too small. configure.in was modified to check for the get_current_dir_name function too. I hope I am following GCS now.

Giuseppe Scivano


--- configure.in.old	2005-07-29 18:14:02.000000000 +0200
+++ configure.in	2005-07-29 18:19:26.000000000 +0200
@@ -2414,7 +2414,7 @@
 AC_CHECK_HEADERS(maillock.h)
 
 AC_CHECK_FUNCS(gethostname getdomainname dup2 \
-rename closedir mkdir rmdir sysinfo getrusage \
+rename closedir mkdir rmdir sysinfo getrusage get_current_dir_name \
 random lrand48 bcopy bcmp logb frexp fmod rint cbrt ftime res_init setsid \
 strerror fpathconf select mktime euidaccess getpagesize tzset setlocale \
 utimes setrlimit setpgid getcwd getwd shutdown getaddrinfo \
--- src/buffer.c.old	2005-07-28 19:14:42.000000000 +0200
+++ src/buffer.c	2005-07-30 03:20:36.000000000 +0200
@@ -31,10 +31,6 @@
 extern int errno;
 #endif
 
-#ifndef MAXPATHLEN
-/* in 4.1 [probably SunOS? -stef] , param.h fails to define this. */
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
 
 #ifdef HAVE_UNISTD_H
 #include <unistd.h>
@@ -5114,7 +5110,7 @@
 void
 init_buffer ()
 {
-  char buf[MAXPATHLEN + 1];
+  char *buf;
   char *pwd;
   struct stat dotstat, pwdstat;
   Lisp_Object temp;
@@ -5140,20 +5136,64 @@
   /* If PWD is accurate, use it instead of calling getwd.  PWD is
      sometimes a nicer name, and using it may avoid a fatal error if a
      parent directory is searchable but not readable.  */
-  if ((pwd = getenv ("PWD")) != 0
+    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);
-#ifdef HAVE_GETCWD
-  else if (getcwd (buf, MAXPATHLEN+1) == 0)
-    fatal ("`getcwd' failed: %s\n", strerror (errno));
+#ifdef MAXPATHLEN
+      && strlen (pwd) < MAXPATHLEN
+#endif
+      )
+    {
+      buf = xmalloc (strlen (pwd) + 1);
+      strcpy (buf, pwd);
+    }
+#ifdef HAVE_CURRENT_DIR_NAME
+  else
+    {
+      buf = get_current_dir_name ();
+      if(!buf)
+        fatal ("`get_current_dir_name' failed in init_buffer\n");
+    }
+#elif HAVE_GETCWD
+  else
+    {
+#ifdef MAXPATHLEN
+      buf = xmalloc (MAXPATHLEN + 1);
+      if(getcwd (buf, MAXPATHLEN + 1) == 0)
+        fatal ("`getwd' failed: %s\n", buf);   
+#else 
+      {
+        int buf_size = 2;
+        buf = xmalloc (buf_size);
+        for(;;)
+          {
+            if(getcwd (buf, buf_size) == 0)
+              {
+                if(errno == ERANGE)
+                  {
+                    buf_size *= 2;
+                    buf = xrealloc (buf, buf_size);
+                  }
+                else
+                  fatal ("`getcwd' failed: %s\n", strerror (errno));
+              }
+            else
+              break;
+          }
+
+      }     
+#endif
+    }
 #else
-  else if (getwd (buf) == 0)
-    fatal ("`getwd' failed: %s\n", buf);
+  else
+    {
+      buf = xmalloc (MAXPATHLEN + 1);
+      if(getwd (buf) == 0)
+        fatal ("`getwd' failed: %s\n", buf); 
+    }
 #endif
 
 #ifndef VMS
@@ -5189,6 +5229,12 @@
 
   temp = get_minibuffer (0);
   XBUFFER (temp)->directory = current_buffer->directory;
+
+#ifdef HAVE_CURRENT_DIR_NAME
+  free (buf);
+#else
+  xfree (buf);
+#endif
 }
 
 /* initialize the buffer routines */
--- src/xsmfns.c.old	2005-07-28 19:51:24.000000000 +0200
+++ src/xsmfns.c	2005-07-30 03:29:19.000000000 +0200
@@ -45,6 +45,8 @@
 #include <sys/param.h>
 #include <stdio.h>
 
+#include <errno.h>
+
 #include "systime.h"
 #include "sysselect.h"
 #include "lisp.h"
@@ -52,10 +54,6 @@
 #include "termopts.h"
 #include "xterm.h"
 
-#ifndef MAXPATHLEN
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
-
 
 /* The user login name.  */
 
@@ -205,7 +203,7 @@
   int val_idx = 0;
   int props_idx = 0;
 
-  char cwd[MAXPATHLEN+1];
+  char *cwd = NULL;
   char *smid_opt;
 
   /* How to start a new instance of Emacs.  */
@@ -259,12 +257,42 @@
   props[props_idx]->vals[0].value = SDATA (Vuser_login_name);
   ++props_idx;
 
-  /* The current directory property, not mandatory.  */
-#ifdef HAVE_GETCWD
-  if (getcwd (cwd, MAXPATHLEN+1) != 0)
+#ifdef HAVE_GET_CURRENT_DIR_NAME
+  cwd = get_current_dir_name ();
+#elif HAVE_GETCWD
+  {
+    int cwd_size = 2;
+    cwd = xmalloc (cwd_size);
+    for(;;)
+      {
+        if(getcwd (cwd, cwd_size) == 0)
+          {
+            if(errno == ERANGE)
+              {
+                cwd_size *= 2;
+                cwd = xrealloc (cwd, cwd_size);
+              }
+            else
+              {
+                xfree (cwd);
+                cwd = NULL;
+              }
+          }
+        else
+          break;
+      }
+    
+  }  
 #else
-  if (getwd (cwd) != 0)
+  cwd = xmalloc (MAXPATHLEN + 1);
+  if(getwd (cwd) == 0)
+    {
+      xfree (cwd);
+      cwd = NULL;
+    }
 #endif
+
+  if(!cwd)
     {
       props[props_idx] = &prop_ptr[props_idx];
       props[props_idx]->name = SmCurrentDirectory;
@@ -281,6 +309,13 @@
 
   xfree (smid_opt);
 
+  if(cwd)
+#ifdef HAVE_CURRENT_DIR_NAME
+    free (cwd);
+#else
+    xfree (cwd);
+#endif
+
   /* See if we maybe shall interact with the user.  */
   if (interactStyle != SmInteractStyleAny
       || ! shutdown

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    > +      buf = malloc(strlen(pwd)+1);
    > +      if(!buf)
    > +        fatal ("`malloc' failed in init_buffer\n");

    This should have used xmalloc instead of calling malloc and checking
    for errors.

Actually I don't think so.  xmalloc reports errors using Fsignal, and
that is the wrong thing to do, this early in Emacs startup.

It might be ok just to use abort, since it should not be possible
to run out of memory at that point.

In xsmfns.c, it would be right to use xmalloc.

Re: emacs & MAXPATHLEN

[Eli Zaretskii]

> From: Giuseppe Scrivano <gscrivano@gmail.com>
> Date: Sat, 30 Jul 2005 03:31:48 +0200
> Cc: emacs-devel@gnu.org
> 
> +      if(getcwd (buf, MAXPATHLEN + 1) == 0)
> +        fatal ("`getwd' failed: %s\n", buf);   

The error message mentions the wrong function here.

I also wonder whether we should keep the "#ifdef MAXPATHLEN" branch,
or just use the loop below on all platforms that have getcwd.

> +#else 
> +      {
> +        int buf_size = 2;
> +        buf = xmalloc (buf_size);
> +        for(;;)
> +          {
> +            if(getcwd (buf, buf_size) == 0)
> +              {
> +                if(errno == ERANGE)
> +                  {
> +                    buf_size *= 2;
> +                    buf = xrealloc (buf, buf_size);
> +                  }
> +                else
> +                  fatal ("`getcwd' failed: %s\n", strerror (errno));
> +              }
> +            else
> +              break;
> +          }
> +
> +      }     
> +#endif

Re: emacs & MAXPATHLEN

[Jan D.]

>
>> +#else
>> +      {
>> +        int buf_size = 2;
>> +        buf = xmalloc (buf_size);
>> +        for(;;)
>> +          {
>> +            if(getcwd (buf, buf_size) == 0)
>> +              {
>> +                if(errno == ERANGE)
>> +                  {
>> +                    buf_size *= 2;
>> +                    buf = xrealloc (buf, buf_size);
>> +                  }
>> +                else
>> +                  fatal ("`getcwd' failed: %s\n", strerror (errno));
>> +              }
>> +            else
>> +              break;
>> +          }
>> +
>> +      }
>> +#endif
>>

You can initialize buf_size to something bigger than 2.  This almost  
guarantees multiple calls to realloc.  Try 1024 or something more  
reasonable that will at least hold most paths.  2 will only hold "/"  
and nothing else.

Also, space after if and for.

     Jan D.

Re: emacs & MAXPATHLEN

[Alfred M. Szmidt]

   --- src/buffer.c.old	2005-07-28 19:14:42.000000000 +0200
   +++ src/buffer.c	2005-07-30 03:20:36.000000000 +0200
...
   +      {
   +        int buf_size = 2;
   +        buf = xmalloc (buf_size);
   +        for(;;)
   +          {
   +            if(getcwd (buf, buf_size) == 0)
   +              {
   +                if(errno == ERANGE)
   +                  {
   +                    buf_size *= 2;
   +                    buf = xrealloc (buf, buf_size);
   +                  }
   +                else
   +                  fatal ("`getcwd' failed: %s\n", strerror (errno));
   +              }
   +            else
   +              break;
   +          }
   +
   +      }     

How about the following instead...  It is far cleaner and easier to
understand.

 int buf_size = 100;
 while (1)
   {
      buf = (char *) xmalloc (buf_size);
      if (getcwd (buf, buf_size) == buf)
        break;
      if (errno != ERANGE)
        {
	  free (buf);
          fatal ("`getcwd' failed: %s\n", strerror (errno));
        }
      size *= 2;
    }

Re: emacs & MAXPATHLEN

[Alfred M. Szmidt]

   I also wonder whether we should keep the "#ifdef MAXPATHLEN"
   branch, or just use the loop below on all platforms that have
   getcwd.

If MAXPATHLEN is defined, it should be respected, if you try to use a
file name that is longer than MAXPATHLEN then the behaviour of the
system is undefined.  Maybe just something like:

#ifdef MAXPATHLEN
  if (buf_size >= MAXPATHLEN)
    break;
#endif

Would be sufficient for platforms with MAXPATHLEN, and then just use
that in the loop.

Re: emacs & MAXPATHLEN

[Jan D.]

>
> How about the following instead...  It is far cleaner and easier to
> understand.
>
>  int buf_size = 100;
>  while (1)
>    {
>       buf = (char *) xmalloc (buf_size);
>       if (getcwd (buf, buf_size) == buf)
>         break;
>       if (errno != ERANGE)
>         {
>       free (buf);
>           fatal ("`getcwd' failed: %s\n", strerror (errno));
>         }
>       size *= 2;
>     }


and leaks memory.  If the path is 400, you do 3 mallocs, but the  
first two are never freed.

     Jan D.

Re: emacs & MAXPATHLEN

[Alfred M. Szmidt]

   and leaks memory.  If the path is 400, you do 3 mallocs, but the
   first two are never freed.

That is just a small matter of moving the free outside the if. :-)

 int buf_size = 100;
 while (1)
   {
      buf = (char *) xmalloc (buf_size);
      if (getcwd (buf, buf_size) == buf)
        break;
      free (buf);
      if (errno != ERANGE)
          fatal ("`getcwd' failed: %s\n", strerror (errno));
      size *= 2;
   }

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

In my opinion it is better to alloc directly MAXPATHLEN+1 bytes when that limit exists without entering the loop and use multiple reallocations.

Giuseppe Scrivano

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

Well.. this code seems cleaner than the older one and without memory leaks :)

"Alfred M\. Szmidt" <ams@gnu.org> writes:

>    and leaks memory.  If the path is 400, you do 3 mallocs, but the
>    first two are never freed.
>
> That is just a small matter of moving the free outside the if. :-)
>
>  int buf_size = 100;
>  while (1)
>    {
>       buf = (char *) xmalloc (buf_size);
>       if (getcwd (buf, buf_size) == buf)
>         break;
>       free (buf);
>       if (errno != ERANGE)
>           fatal ("`getcwd' failed: %s\n", strerror (errno));
>       size *= 2;
>    }

Re: emacs & MAXPATHLEN

[Andreas Schwab]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    and leaks memory.  If the path is 400, you do 3 mallocs, but the
>    first two are never freed.
>
> That is just a small matter of moving the free outside the if. :-)
>
>  int buf_size = 100;
>  while (1)
>    {
>       buf = (char *) xmalloc (buf_size);
>       if (getcwd (buf, buf_size) == buf)
>         break;
>       free (buf);
>       if (errno != ERANGE)

At this point errno may already be changed by free().  Why not just use
xrealloc in the first place?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

This new version should follow all your hints:

--- configure.in.old	2005-07-29 18:14:02.000000000 +0200
+++ configure.in	2005-07-29 18:19:26.000000000 +0200
@@ -2414,7 +2414,7 @@
 AC_CHECK_HEADERS(maillock.h)
 
 AC_CHECK_FUNCS(gethostname getdomainname dup2 \
-rename closedir mkdir rmdir sysinfo getrusage \
+rename closedir mkdir rmdir sysinfo getrusage get_current_dir_name \
 random lrand48 bcopy bcmp logb frexp fmod rint cbrt ftime res_init setsid \
 strerror fpathconf select mktime euidaccess getpagesize tzset setlocale \
 utimes setrlimit setpgid getcwd getwd shutdown getaddrinfo \
--- src/buffer.c.old	2005-07-28 19:14:42.000000000 +0200
+++ src/buffer.c	2005-07-30 15:29:08.000000000 +0200
@@ -31,10 +31,6 @@
 extern int errno;
 #endif
 
-#ifndef MAXPATHLEN
-/* in 4.1 [probably SunOS? -stef] , param.h fails to define this. */
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
 
 #ifdef HAVE_UNISTD_H
 #include <unistd.h>
@@ -5114,7 +5110,7 @@
 void
 init_buffer ()
 {
-  char buf[MAXPATHLEN + 1];
+  char *buf;
   char *pwd;
   struct stat dotstat, pwdstat;
   Lisp_Object temp;
@@ -5140,20 +5136,57 @@
   /* If PWD is accurate, use it instead of calling getwd.  PWD is
      sometimes a nicer name, and using it may avoid a fatal error if a
      parent directory is searchable but not readable.  */
-  if ((pwd = getenv ("PWD")) != 0
+    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);
-#ifdef HAVE_GETCWD
-  else if (getcwd (buf, MAXPATHLEN+1) == 0)
-    fatal ("`getcwd' failed: %s\n", strerror (errno));
+#ifdef MAXPATHLEN
+      && strlen (pwd) < MAXPATHLEN
+#endif
+      )
+    {
+      buf = xmalloc (strlen (pwd) + 1);
+      strcpy (buf, pwd);
+    }
+#ifdef HAVE_CURRENT_DIR_NAME
+  else
+    {
+      buf = get_current_dir_name ();
+      if (!buf)
+        fatal ("`get_current_dir_name' failed in init_buffer\n");
+    }
+#elif HAVE_GETCWD
+  else
+    {
+#ifdef MAXPATHLEN
+      buf = xmalloc (MAXPATHLEN + 1);
+      if (getcwd (buf, MAXPATHLEN + 1) == NULL)
+        fatal ("`getcwd' failed: %s\n", buf);   
+#else 
+      {
+        int buf_size = 1024;
+        buf = (char *) xmalloc (buf_size); 
+        for (;;)
+          {
+            if (getcwd (buf, buf_size) == buf)
+              break;
+            if (errno != ERANGE)
+              fatal ("`getcwd' failed: %s\n", strerror (errno));
+            buf_size *= 2;
+            buf = (char *) xrealloc (buf, buf_size);
+          }
+      }     
+#endif
+    }
 #else
-  else if (getwd (buf) == 0)
-    fatal ("`getwd' failed: %s\n", buf);
+  else
+    {
+      buf = xmalloc (MAXPATHLEN + 1);
+      if (getwd (buf) == NULL)
+        fatal ("`getwd' failed: %s\n", buf); 
+    }
 #endif
 
 #ifndef VMS
@@ -5189,6 +5222,12 @@
 
   temp = get_minibuffer (0);
   XBUFFER (temp)->directory = current_buffer->directory;
+
+#ifdef HAVE_CURRENT_DIR_NAME
+  free (buf);
+#else
+  xfree (buf);
+#endif
 }
 
 /* initialize the buffer routines */
--- src/xsmfns.c.old	2005-07-28 19:51:24.000000000 +0200
+++ src/xsmfns.c	2005-07-30 15:31:16.000000000 +0200
@@ -45,6 +45,8 @@
 #include <sys/param.h>
 #include <stdio.h>
 
+#include <errno.h>
+
 #include "systime.h"
 #include "sysselect.h"
 #include "lisp.h"
@@ -52,10 +54,6 @@
 #include "termopts.h"
 #include "xterm.h"
 
-#ifndef MAXPATHLEN
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
-
 
 /* The user login name.  */
 
@@ -205,7 +203,7 @@
   int val_idx = 0;
   int props_idx = 0;
 
-  char cwd[MAXPATHLEN+1];
+  char *cwd = NULL;
   char *smid_opt;
 
   /* How to start a new instance of Emacs.  */
@@ -259,12 +257,47 @@
   props[props_idx]->vals[0].value = SDATA (Vuser_login_name);
   ++props_idx;
 
-  /* The current directory property, not mandatory.  */
-#ifdef HAVE_GETCWD
-  if (getcwd (cwd, MAXPATHLEN+1) != 0)
+#ifdef HAVE_GET_CURRENT_DIR_NAME
+  cwd = get_current_dir_name ();
+#elif HAVE_GETCWD
+
+#ifdef MAXPATHLEN
+  cwd = (char *) xmalloc (MAXPATHLEN+1);
+   if (getcwd (cwd, MAXPATHLEN+1) == NULL)
+     {
+       xfree(cwd);
+       cwd = NULL;
+     }
 #else
-  if (getwd (cwd) != 0)
+   {
+     int cwd_size = 1024;
+     cwd = (char *) xmalloc (cwd_size); 
+     for (;;)
+       {
+         if (getcwd (cwd, cwd_size) == cwd)
+           break;
+         if (errno != ERANGE)
+           {
+             xfree (cwd);
+             cwd = NULL; 
+             break;
+           }
+         cwd_size *= 2;
+         cwd = (char *) xrealloc (cwd, cwd_size);
+       }
+   }   
 #endif
+
+#else
+  cwd = xmalloc (MAXPATHLEN + 1);
+  if (getwd (cwd) == NULL)
+    {
+      xfree (cwd);
+      cwd = NULL;
+    }
+#endif
+
+  if (!cwd)
     {
       props[props_idx] = &prop_ptr[props_idx];
       props[props_idx]->name = SmCurrentDirectory;
@@ -281,6 +314,13 @@
 
   xfree (smid_opt);
 
+  if (cwd)
+#ifdef HAVE_CURRENT_DIR_NAME
+    free (cwd);
+#else
+    xfree (cwd);
+#endif
+
   /* See if we maybe shall interact with the user.  */
   if (interactStyle != SmInteractStyleAny
       || ! shutdown

Re: emacs & MAXPATHLEN

[Eli Zaretskii]

> From: "Alfred M\. Szmidt" <ams@gnu.org>
> Cc: gscrivano@gmail.com, rms@gnu.org, emacs-devel@gnu.org
> Date: Sat, 30 Jul 2005 13:53:20 +0200
> 
>    I also wonder whether we should keep the "#ifdef MAXPATHLEN"
>    branch, or just use the loop below on all platforms that have
>    getcwd.
> 
> If MAXPATHLEN is defined, it should be respected, if you try to use a
> file name that is longer than MAXPATHLEN then the behaviour of the
> system is undefined.

??? How can a file name on a system be ever longer than MAXPATHLEN,
which is a system-dependent limit?  Presumably, the value of
MAXPATHLEN is set to fit the longest possible file name on the
underlying file system.

Re: emacs & MAXPATHLEN

[Alfred M. Szmidt]

   ??? How can a file name on a system be ever longer than MAXPATHLEN,
   which is a system-dependent limit?

Ack, I was thinking of a different case... Ignore me...

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

Could you make a single subroutine and call it from both
buffer.c and xsmfns.c?

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

"Richard M. Stallman" <rms@gnu.org> writes:

> Could you make a single subroutine and call it from both
> buffer.c and xsmfns.c?


I created two new files: cwd.h and cwd.c with the routine. This new patch uses them. Now src/Makefile.in is modified too:

--- configure.in.old	2005-07-29 18:14:02.000000000 +0200
+++ configure.in	2005-07-29 18:19:26.000000000 +0200
@@ -2414,7 +2414,7 @@
 AC_CHECK_HEADERS(maillock.h)
 
 AC_CHECK_FUNCS(gethostname getdomainname dup2 \
-rename closedir mkdir rmdir sysinfo getrusage \
+rename closedir mkdir rmdir sysinfo getrusage get_current_dir_name \
 random lrand48 bcopy bcmp logb frexp fmod rint cbrt ftime res_init setsid \
 strerror fpathconf select mktime euidaccess getpagesize tzset setlocale \
 utimes setrlimit setpgid getcwd getwd shutdown getaddrinfo \
--- src/Makefile.in.old	2005-07-30 18:28:12.000000000 +0200
+++ src/Makefile.in	2005-07-30 18:15:26.000000000 +0200
@@ -587,7 +587,7 @@
 	alloc.o data.o doc.o editfns.o callint.o \
 	eval.o floatfns.o fns.o print.o lread.o \
 	abbrev.o syntax.o UNEXEC bytecode.o \
-	process.o callproc.o \
+	process.o cwd.o callproc.o \
 	region-cache.o sound.o atimer.o \
 	doprnt.o strftime.o intervals.o textprop.o composite.o md5.o \
 	$(MSDOS_OBJ) $(MAC_OBJ) $(CYGWIN_OBJ)
@@ -1078,6 +1078,7 @@
 cm.o: cm.c cm.h termhooks.h $(config_h)
 cmds.o: cmds.c syntax.h buffer.h charset.h commands.h window.h $(config_h) \
 	msdos.h dispextern.h keyboard.h keymap.h
+cwd.o: cwd.c cwd.h $(config_h)
 pre-crt0.o: pre-crt0.c
 ecrt0.o: ecrt0.c $(config_h)
 	CRT0_COMPILE ${srcdir}/ecrt0.c
--- src/cwd.h.old	1970-01-01 01:00:00.000000000 +0100
+++ src/cwd.h	2005-07-30 18:06:43.000000000 +0200
@@ -0,0 +1,24 @@
+/* Header file for the curret working directory routine.
+   Copyright (C) 1985, 1986, 1993, 1994, 1995, 1997, 1998, 1999, 2000, 2001,
+     2003, 2004, 2005  Free Software Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs; see the file COPYING.  If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+Boston, MA 02110-1301, USA.  */
+
+
+
+extern char * get_cwd ();
--- src/cwd.c.old	1970-01-01 01:00:00.000000000 +0100
+++ src/cwd.c	2005-07-30 19:04:03.000000000 +0200
@@ -0,0 +1,125 @@
+/* Get current working directory routine for GNU Emacs.
+   Copyright (C) 1985, 86, 87, 88, 89, 93, 94, 95, 97, 98, 99,
+     2000, 01, 02, 03, 04, 2005 Free Software Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs; see the file COPYING.  If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+Boston, MA 02110-1301, USA.  */
+
+#include <config.h>
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/param.h>
+#include <errno.h>
+#include <stdio.h>
+
+#include "lisp.h"
+
+#ifndef USE_CRT_DLL
+extern int errno;
+#endif
+
+
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif
+
+/* Return the current working directory.  Returns NULL on errors. 
+   Any other returned value must be freed with free.  */
+char*
+get_cwd ()
+{
+  char *buf;
+  char *pwd;
+  struct stat dotstat, pwdstat;
+  /* If PWD is accurate, use it instead of calling getwd.  PWD is
+     sometimes a nicer name, and using it may avoid a fatal error if a
+     parent directory is searchable but not readable.  */
+    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
+#ifdef MAXPATHLEN
+      && strlen (pwd) < MAXPATHLEN
+#endif
+      )
+    {
+      buf = (char *) malloc (strlen (pwd) + 1);
+      if (!buf)
+        return NULL;
+      strcpy (buf, pwd);
+    }
+#ifdef HAVE_CURRENT_DIR_NAME
+  else
+    {
+      buf = get_current_dir_name ();
+      if (!buf)
+        return NULL;
+    }
+#elif HAVE_GETCWD
+  else
+    {
+#ifdef MAXPATHLEN
+      buf = (char *) malloc (MAXPATHLEN + 1);
+      if (!buf)
+        return NULL;
+      if (getcwd (buf, MAXPATHLEN + 1) == NULL)
+        return NULL;
+#else 
+      {
+        size_t buf_size = 1024;
+        buf = (char *) malloc (buf_size); 
+        if (!buf)
+          return NULL;
+        for (;;)
+          {
+            if (getcwd (buf, buf_size) == buf)
+              break;
+            if (errno != ERANGE)
+              {
+                int tmp_errno = errno;
+                free (buf);
+                errno = tmp_errno;
+                return NULL;
+              }
+            buf_size *= 2;
+            buf = (char *) realloc (buf, buf_size);
+            if (!buf)
+              return NULL;
+          }
+      }     
+#endif
+    }
+#else
+  else
+    {
+      buf = (char *) malloc (MAXPATHLEN + 1);
+      if (!buf)
+        return NULL;
+      if (getwd (buf) == NULL)
+        {
+          int tmp_errno = errno;
+          free (buf);
+          errno = tmp_errno;
+          return NULL;
+        }
+    }
+#endif
+  return buf;
+}
--- src/buffer.c.old	2005-07-28 19:14:42.000000000 +0200
+++ src/buffer.c	2005-07-30 18:42:20.000000000 +0200
@@ -31,10 +31,6 @@
 extern int errno;
 #endif
 
-#ifndef MAXPATHLEN
-/* in 4.1 [probably SunOS? -stef] , param.h fails to define this. */
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
 
 #ifdef HAVE_UNISTD_H
 #include <unistd.h>
@@ -52,6 +48,7 @@
 #include "keyboard.h"
 #include "keymap.h"
 #include "frame.h"
+#include "cwd.h"
 
 struct buffer *current_buffer;		/* the current buffer */
 
@@ -5114,7 +5111,6 @@
 void
 init_buffer ()
 {
-  char buf[MAXPATHLEN + 1];
   char *pwd;
   struct stat dotstat, pwdstat;
   Lisp_Object temp;
@@ -5137,37 +5133,23 @@
   if (NILP (buffer_defaults.enable_multibyte_characters))
     Fset_buffer_multibyte (Qnil);
 
-  /* If PWD is accurate, use it instead of calling getwd.  PWD is
-     sometimes a nicer name, and using it may avoid a fatal error if a
-     parent directory is searchable but not readable.  */
-  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);
-#ifdef HAVE_GETCWD
-  else if (getcwd (buf, MAXPATHLEN+1) == 0)
-    fatal ("`getcwd' failed: %s\n", strerror (errno));
-#else
-  else if (getwd (buf) == 0)
-    fatal ("`getwd' failed: %s\n", buf);
-#endif
+  pwd = get_cwd ();
+ 
+  if(!pwd)
+    fatal ("`get_cwd' failed: %s\n", strerror (errno)); 
 
 #ifndef VMS
   /* Maybe this should really use some standard subroutine
      whose definition is filename syntax dependent.  */
-  rc = strlen (buf);
-  if (!(IS_DIRECTORY_SEP (buf[rc - 1])))
+  rc = strlen (pwd);
+  if (!(IS_DIRECTORY_SEP (pwd[rc - 1])))
     {
-      buf[rc] = DIRECTORY_SEP;
-      buf[rc + 1] = '\0';
+      pwd[rc] = DIRECTORY_SEP;
+      pwd[rc + 1] = '\0';
     }
 #endif /* not VMS */
 
-  current_buffer->directory = make_unibyte_string (buf, strlen (buf));
+  current_buffer->directory = make_unibyte_string (pwd, strlen (pwd));
   if (! NILP (buffer_defaults.enable_multibyte_characters))
     /* At this momemnt, we still don't know how to decode the
        direcotry name.  So, we keep the bytes in multibyte form so
@@ -5189,6 +5171,8 @@
 
   temp = get_minibuffer (0);
   XBUFFER (temp)->directory = current_buffer->directory;
+
+  free (pwd);
 }
 
 /* initialize the buffer routines */
--- src/xsmfns.c.old	2005-07-28 19:51:24.000000000 +0200
+++ src/xsmfns.c	2005-07-30 19:11:29.000000000 +0200
@@ -51,11 +51,7 @@
 #include "termhooks.h"
 #include "termopts.h"
 #include "xterm.h"
-
-#ifndef MAXPATHLEN
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
-
+#include "cwd.h"
 
 /* The user login name.  */
 
@@ -205,7 +201,7 @@
   int val_idx = 0;
   int props_idx = 0;
 
-  char cwd[MAXPATHLEN+1];
+  char *cwd = NULL;
   char *smid_opt;
 
   /* How to start a new instance of Emacs.  */
@@ -259,12 +255,9 @@
   props[props_idx]->vals[0].value = SDATA (Vuser_login_name);
   ++props_idx;
 
-  /* The current directory property, not mandatory.  */
-#ifdef HAVE_GETCWD
-  if (getcwd (cwd, MAXPATHLEN+1) != 0)
-#else
-  if (getwd (cwd) != 0)
-#endif
+  cwd = get_cwd ();
+
+  if (cwd)
     {
       props[props_idx] = &prop_ptr[props_idx];
       props[props_idx]->name = SmCurrentDirectory;
@@ -281,6 +274,9 @@
 
   xfree (smid_opt);
 
+  if (cwd)
+    free (cwd);
+
   /* See if we maybe shall interact with the user.  */
   if (interactStyle != SmInteractStyleAny
       || ! shutdown

Re: emacs & MAXPATHLEN

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> ??? How can a file name on a system be ever longer than MAXPATHLEN,
> which is a system-dependent limit?

You can easily create a deeply nested directory whose absolute file name
is longer than MAXPATHLEN.  The MAXPATHLEN (a.k.a PATH_MAX) parameter only
limits the length of the file name that can be passed to system calls, but
has no connection to maximum length of an (absoulte) file name in a system
(you can create virtually infinite long file names on Linux, for example).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs & MAXPATHLEN

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: ams@gnu.org, gscrivano@gmail.com, rms@gnu.org,
> 	emacs-devel@gnu.org
> Date: Sat, 30 Jul 2005 19:35:19 +0200
> 
> You can easily create a deeply nested directory whose absolute file name
> is longer than MAXPATHLEN.  The MAXPATHLEN (a.k.a PATH_MAX) parameter only
> limits the length of the file name that can be passed to system calls, but
> has no connection to maximum length of an (absoulte) file name in a system
> (you can create virtually infinite long file names on Linux, for example).

But in this case, the file name we are talking about was _produced_ by
a function, i.e. by some system call.  I don't think such a file name
can exceed the syscall limits, can it?

Re: emacs & MAXPATHLEN

[Jan D.]

>> You can easily create a deeply nested directory whose absolute  
>> file name
>> is longer than MAXPATHLEN.  The MAXPATHLEN (a.k.a PATH_MAX)  
>> parameter only
>> limits the length of the file name that can be passed to system  
>> calls, but
>> has no connection to maximum length of an (absoulte) file name in  
>> a system
>> (you can create virtually infinite long file names on Linux, for  
>> example).
>>
>
> But in this case, the file name we are talking about was _produced_ by
> a function, i.e. by some system call.  I don't think such a file name
> can exceed the syscall limits, can it?

Well, if you have a directory on one filesystem with MAXPATHLEN and  
then mount another filesystem under that directory, that would make  
all paths in the mounted file system exceed MAXPATHLEN.  In theory at  
least, I haven't tried it.

     Jan D.

Re: emacs & MAXPATHLEN

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> But in this case, the file name we are talking about was _produced_ by
> a function, i.e. by some system call.  I don't think such a file name
> can exceed the syscall limits, can it?

You don't need an absolute file name to create a file.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    If MAXPATHLEN is defined, it should be respected, if you try to use a
    file name that is longer than MAXPATHLEN then the behaviour of the
    system is undefined.

It's better to try to get the cwd than not try.
It might work.  And if it doesn't, we have lost nothing.

Someone wrote:

    In my opinion it is better to alloc directly MAXPATHLEN+1 bytes
    when that limit exists without entering the loop and use multiple
    reallocations.

It's best to keep the code simple, all else being equal,
and reduce the number of conditionals.

Eliz wrote:

    ??? How can a file name on a system be ever longer than MAXPATHLEN,
    which is a system-dependent limit?

Do mkdir -p /a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z, then
rename each directory one by one from the bottom upward to a long
name, and whoopee!  This was first done on Multics, and resulted
in a file that could not be deleted except by renaming the directories
back to short names, from the top down.

I think it was called a Frankston bush.

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

> Someone wrote:
>
>     In my opinion it is better to alloc directly MAXPATHLEN+1 bytes
>     when that limit exists without entering the loop and use multiple
>     reallocations.
>
> It's best to keep the code simple, all else being equal,
> and reduce the number of conditionals.

To keep the code simple we can remove the #ifdef MAXPATHLEN...#endif piece in the HAVE_GETCWD part.  In this way we use always the loop both if MAXPATHLEN is defined or not.  
Anyway, checking for the MAXPATHLEN inside the loop doesn't change the number of switches, if we want to check for the limit I suggest to have the check outside the loop and avoid multiple reallocations.

Giuseppe Scrivano

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

1. I'd rather put this in sysdep.c and avoid the hassle of
two new files.

2. It could be called get_current_dir_name,
and defined only when the system does not define it.
That would simplify things.

3. I'd rather not include this:

+#ifdef MAXPATHLEN
+      buf = (char *) malloc (MAXPATHLEN + 1);
+      if (!buf)
+        return NULL;
+      if (getcwd (buf, MAXPATHLEN + 1) == NULL)
+        return NULL;
+#else 

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    (you can create virtually infinite long file names on Linux, for example).

You can't create them on Linux by itself.  To execute a system call,
you need GNU libc too.  So I think you mean "on GNU/Linux", not "on
Linux".

Re: emacs & MAXPATHLEN

[Andreas Schwab]

"Richard M. Stallman" <rms@gnu.org> writes:

>     (you can create virtually infinite long file names on Linux, for example).
>
> You can't create them on Linux by itself.

Sure you can.

>  To execute a system call, you need GNU libc too.

No, you don't.

> So I think you mean "on GNU/Linux", not "on Linux".

No, my statement is perfectly correct.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs & MAXPATHLEN

[Giuseppe Scrivano]

"Richard M. Stallman" <rms@gnu.org> writes:

> 1. I'd rather put this in sysdep.c and avoid the hassle of
> two new files.
Done.

> 2. It could be called get_current_dir_name,
> and defined only when the system does not define it.
> That would simplify things.
Done.

> 3. I'd rather not include this:
>
> +#ifdef MAXPATHLEN
> +      buf = (char *) malloc (MAXPATHLEN + 1);
> +      if (!buf)
> +        return NULL;
> +      if (getcwd (buf, MAXPATHLEN + 1) == NULL)
> +        return NULL;
> +#else 
Done.

Giuseppe Scrivano

This is the new patch, please let me know if you have other comments or suggestions:

--- configure.in.old	2005-07-29 18:14:02.000000000 +0200
+++ configure.in	2005-07-29 18:19:26.000000000 +0200
@@ -2414,7 +2414,7 @@
 AC_CHECK_HEADERS(maillock.h)
 
 AC_CHECK_FUNCS(gethostname getdomainname dup2 \
-rename closedir mkdir rmdir sysinfo getrusage \
+rename closedir mkdir rmdir sysinfo getrusage get_current_dir_name \
 random lrand48 bcopy bcmp logb frexp fmod rint cbrt ftime res_init setsid \
 strerror fpathconf select mktime euidaccess getpagesize tzset setlocale \
 utimes setrlimit setpgid getcwd getwd shutdown getaddrinfo \
--- src/sysdep.c.old	2005-07-27 13:54:24.000000000 +0200
+++ src/sysdep.c	2005-08-01 15:28:44.000000000 +0200
@@ -258,6 +258,81 @@
 
 SIGMASKTYPE sigprocmask_set;
 
+
+#ifndef HAVE_CURRENT_DIR_NAME
+
+/* Return the current working directory.  Returns NULL on errors. 
+   Any other returned value must be freed with free. This is used
+   only when get_current_dir_name s not yet defined on the system.  */
+char*
+get_current_dir_name ()
+{
+  char *buf;
+  char *pwd;
+  struct stat dotstat, pwdstat;
+  /* If PWD is accurate, use it instead of calling getwd.  PWD is
+     sometimes a nicer name, and using it may avoid a fatal error if a
+     parent directory is searchable but not readable.  */
+    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
+#ifdef MAXPATHLEN
+      && strlen (pwd) < MAXPATHLEN
+#endif
+      )
+    {
+      buf = (char *) malloc (strlen (pwd) + 1);
+      if (!buf)
+        return NULL;
+      strcpy (buf, pwd);
+    }
+#ifdef HAVE_GETCWD
+  else
+    {
+      size_t buf_size = 1024;
+      buf = (char *) malloc (buf_size); 
+      if (!buf)
+        return NULL;
+      for (;;)
+        {
+          if (getcwd (buf, buf_size) == buf)
+            break;
+          if (errno != ERANGE)
+            {
+              int tmp_errno = errno;
+              free (buf);
+              errno = tmp_errno;
+              return NULL;
+            }
+          buf_size *= 2;
+          buf = (char *) realloc (buf, buf_size);
+          if (!buf)
+            return NULL;
+        }   
+#endif
+    }
+#else
+  else
+    {
+      buf = (char *) malloc (MAXPATHLEN + 1);
+      if (!buf)
+        return NULL;
+      if (getwd (buf) == NULL)
+        {
+          int tmp_errno = errno;
+          free (buf);
+          errno = tmp_errno;
+          return NULL;
+        }
+    }
+#endif
+  return buf;
+}
+#endif
+
 \f
 /* Specify a different file descriptor for further input operations.  */
 
--- src/buffer.c.old	2005-07-28 19:14:42.000000000 +0200
+++ src/buffer.c	2005-08-01 15:13:38.000000000 +0200
@@ -31,10 +31,6 @@
 extern int errno;
 #endif
 
-#ifndef MAXPATHLEN
-/* in 4.1 [probably SunOS? -stef] , param.h fails to define this. */
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
 
 #ifdef HAVE_UNISTD_H
 #include <unistd.h>
@@ -53,6 +49,8 @@
 #include "keymap.h"
 #include "frame.h"
 
+extern char * get_current_dir_name ();
+
 struct buffer *current_buffer;		/* the current buffer */
 
 /* First buffer in chain of all buffers (in reverse order of creation).
@@ -5114,7 +5112,6 @@
 void
 init_buffer ()
 {
-  char buf[MAXPATHLEN + 1];
   char *pwd;
   struct stat dotstat, pwdstat;
   Lisp_Object temp;
@@ -5137,37 +5134,23 @@
   if (NILP (buffer_defaults.enable_multibyte_characters))
     Fset_buffer_multibyte (Qnil);
 
-  /* If PWD is accurate, use it instead of calling getwd.  PWD is
-     sometimes a nicer name, and using it may avoid a fatal error if a
-     parent directory is searchable but not readable.  */
-  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);
-#ifdef HAVE_GETCWD
-  else if (getcwd (buf, MAXPATHLEN+1) == 0)
-    fatal ("`getcwd' failed: %s\n", strerror (errno));
-#else
-  else if (getwd (buf) == 0)
-    fatal ("`getwd' failed: %s\n", buf);
-#endif
+  pwd = get_current_dir_name ();
+ 
+  if(!pwd)
+    fatal ("`get_cwd' failed: %s\n", strerror (errno)); 
 
 #ifndef VMS
   /* Maybe this should really use some standard subroutine
      whose definition is filename syntax dependent.  */
-  rc = strlen (buf);
-  if (!(IS_DIRECTORY_SEP (buf[rc - 1])))
+  rc = strlen (pwd);
+  if (!(IS_DIRECTORY_SEP (pwd[rc - 1])))
     {
-      buf[rc] = DIRECTORY_SEP;
-      buf[rc + 1] = '\0';
+      pwd[rc] = DIRECTORY_SEP;
+      pwd[rc + 1] = '\0';
     }
 #endif /* not VMS */
 
-  current_buffer->directory = make_unibyte_string (buf, strlen (buf));
+  current_buffer->directory = make_unibyte_string (pwd, strlen (pwd));
   if (! NILP (buffer_defaults.enable_multibyte_characters))
     /* At this momemnt, we still don't know how to decode the
        direcotry name.  So, we keep the bytes in multibyte form so
@@ -5189,6 +5172,8 @@
 
   temp = get_minibuffer (0);
   XBUFFER (temp)->directory = current_buffer->directory;
+
+  free (pwd);
 }
 
 /* initialize the buffer routines */
--- src/xsmfns.c.old	2005-07-28 19:51:24.000000000 +0200
+++ src/xsmfns.c	2005-08-01 15:13:46.000000000 +0200
@@ -52,10 +52,7 @@
 #include "termopts.h"
 #include "xterm.h"
 
-#ifndef MAXPATHLEN
-#define MAXPATHLEN 1024
-#endif /* not MAXPATHLEN */
-
+extern char * get_current_dir_name ();
 
 /* The user login name.  */
 
@@ -205,7 +202,7 @@
   int val_idx = 0;
   int props_idx = 0;
 
-  char cwd[MAXPATHLEN+1];
+  char *cwd = NULL;
   char *smid_opt;
 
   /* How to start a new instance of Emacs.  */
@@ -259,12 +256,9 @@
   props[props_idx]->vals[0].value = SDATA (Vuser_login_name);
   ++props_idx;
 
-  /* The current directory property, not mandatory.  */
-#ifdef HAVE_GETCWD
-  if (getcwd (cwd, MAXPATHLEN+1) != 0)
-#else
-  if (getwd (cwd) != 0)
-#endif
+  cwd = get_current_dir_name ();
+
+  if (cwd)
     {
       props[props_idx] = &prop_ptr[props_idx];
       props[props_idx]->name = SmCurrentDirectory;
@@ -281,6 +275,9 @@
 
   xfree (smid_opt);
 
+  if (cwd)
+    free (cwd);
+
   /* See if we maybe shall interact with the user.  */
   if (interactStyle != SmInteractStyleAny
       || ! shutdown

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    > You can't create them on Linux by itself.

    Sure you can.

If all that's on the machine is Linux, you can't type commands, and
even running user programs would not be easy.

Weren't you in fact running a GNU/Linux system?

Re: emacs & MAXPATHLEN

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > You can't create them on Linux by itself.
>
>     Sure you can.
>
> If all that's on the machine is Linux, you can't type commands, and
> even running user programs would not be easy.
>
> Weren't you in fact running a GNU/Linux system?

Probably, but not certainly:
<URL:http://www.skarnet.org/poweredby.html>

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs & MAXPATHLEN

[Andreas Schwab]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > You can't create them on Linux by itself.
>
>     Sure you can.
>
> If all that's on the machine is Linux, you can't type commands, and
> even running user programs would not be easy.

You can run Linux with just a suitable initramfs using klibc.  That's
enough for running a firewall, for example.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    You can run Linux with just a suitable initramfs using klibc.

I am not sure what an initramfs is, or what klibc is.  But I don't
think that this could include programs such as Emacs, and the other
programs you need to run Emacs, without being a lot more than just
Linux.

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    Probably, but not certainly:
    <URL:http://www.skarnet.org/poweredby.html>

The system running on that machine is not Linux.
It isn't GNU/Linux, but like GNU/Linux, it includes
Linux along with many other programs.

Re: emacs & MAXPATHLEN

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Probably, but not certainly:
>     <URL:http://www.skarnet.org/poweredby.html>
>
> The system running on that machine is not Linux.

Well, it _is_ the "system" in "system call": a "system call" clearly
passes control to Linux.

> It isn't GNU/Linux, but like GNU/Linux, it includes
> Linux along with many other programs.

Linux is not really a program in the usual sense.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs & MAXPATHLEN

[Richard M. Stallman]

    Well, it _is_ the "system" in "system call": a "system call" clearly
    passes control to Linux.

Actually it calls libc, and then libc invokes the kernel.

    > It isn't GNU/Linux, but like GNU/Linux, it includes
    > Linux along with many other programs.

    Linux is not really a program in the usual sense.

It is a program, in the usual sense of the word.
You must have some unusual sense of the word in mind.

Re: emacs & MAXPATHLEN

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Well, it _is_ the "system" in "system call": a "system call" clearly
>     passes control to Linux.
>
> Actually it calls libc, and then libc invokes the kernel.

Uh no.  That is the system call _wrapper_ of the library.  The system
call itself is a trap or software interrupt.

Take a look at a dictionary: <URL:http://en.wikipedia.org/wiki/System_call>

>     > It isn't GNU/Linux, but like GNU/Linux, it includes
>     > Linux along with many other programs.
>
>     Linux is not really a program in the usual sense.
>
> It is a program, in the usual sense of the word.
> You must have some unusual sense of the word in mind.

<URL:http://en.wikipedia.org/wiki/Operating_system>
<URL:http://en.wikipedia.org/wiki/Computer_program>

Looks more like a collection of services to me, somewhat like a
library.  A kernel that runs below a microkernel might be considered
to act partly as a program, at least if the microkernel does the
scheduling.

It's not exactly like any of this should be news to you.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs & MAXPATHLEN

[Sascha Wilde]

[-- Attachment #1.1: Type: text/plain, Size: 1424 bytes --]

On Thu, Aug 04, 2005 at 08:30:05AM +0200, David Kastrup wrote:
> "Richard M. Stallman" <rms@gnu.org> writes:

> >     Linux is not really a program in the usual sense.
> >
> > It is a program, in the usual sense of the word.
> > You must have some unusual sense of the word in mind.
> 
> <URL:http://en.wikipedia.org/wiki/Operating_system>
> <URL:http://en.wikipedia.org/wiki/Computer_program>

Lets have a look:

    Operating system
    From Wikipedia, the free encyclopedia.

    In computing, an operating system (OS) is the system software
    [...]

... well ...

    System software
    From Wikipedia, the free encyclopedia.

    System software is a generic term referring to any computer
    software whose purpose is to help run the computer system.

... ok, so it's "computer software", now, what's that?

    Computer software
    From Wikipedia, the free encyclopedia.

    Computer software (or simply software) refers to one or more
    computer programs held in the storage of a computer for some
    purpose.

... and here we go, it's a "computer program" (what a surprise) --
your second link.  :)

"program" is a very generic term, and I think it's a pretty strange
idea to pretend it isn't...

btw. I think the word for the kind of program you consider the "usual
sense" would be "application".

cheers
sascha
-- 
Sascha Wilde 
- no sig today... sorry!

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacs & MAXPATHLEN

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> On Thu, Aug 04, 2005 at 08:30:05AM +0200, David Kastrup wrote:
>> "Richard M. Stallman" <rms@gnu.org> writes:
>
>> >     Linux is not really a program in the usual sense.
>> >
>> > It is a program, in the usual sense of the word.
>> > You must have some unusual sense of the word in mind.
>> 
>> <URL:http://en.wikipedia.org/wiki/Operating_system>
>> <URL:http://en.wikipedia.org/wiki/Computer_program>
>
> Lets have a look:
>
>     Operating system
>     From Wikipedia, the free encyclopedia.
>
>     In computing, an operating system (OS) is the system software
>     [...]
>
> ... well ...
>
>     System software
>     From Wikipedia, the free encyclopedia.
>
>     System software is a generic term referring to any computer
>     software whose purpose is to help run the computer system.
>
> ... ok, so it's "computer software", now, what's that?
>
>     Computer software
>     From Wikipedia, the free encyclopedia.
>
>     Computer software (or simply software) refers to one or more
>     computer programs held in the storage of a computer for some
>     purpose.
>
> ... and here we go, it's a "computer program" (what a surprise) --
> your second link.  :)

According to your reference interpreting skills, GNU/Linux would count
as just "a computer program", too.  So we are back at square one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs & MAXPATHLEN

[Sascha Wilde]

[-- Attachment #1.1: Type: text/plain, Size: 1580 bytes --]

On Thu, Aug 04, 2005 at 01:13:48PM +0200, David Kastrup wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
> 
> > On Thu, Aug 04, 2005 at 08:30:05AM +0200, David Kastrup wrote:
> >> "Richard M. Stallman" <rms@gnu.org> writes:
> >
> >> >     Linux is not really a program in the usual sense.
> >> >
> >> > It is a program, in the usual sense of the word.
> >> > You must have some unusual sense of the word in mind.
> >> 
> >> <URL:http://en.wikipedia.org/wiki/Operating_system>
> >> <URL:http://en.wikipedia.org/wiki/Computer_program>
> >
> > Lets have a look:
> >
> >     Operating system
> >     From Wikipedia, the free encyclopedia.
> >
> >     In computing, an operating system (OS) is the system software
> >     [...]
[...]
> > ... and here we go, it's a "computer program" (what a surprise) --
> > your second link.  :)
> 
> According to your reference interpreting skills, GNU/Linux would
> count as just "a computer program", too.

Well, not one, many -- but anyway just "computer programs".

Yes, that is exactly my point, I think Richard is right: 
Linux is just a program "in the usual sense".  

And I wanted to show, that even the URLs you posted say the same.  
:-)

cheers
sascha
-- 
Sascha Wilde : VI is to EMACS as masturbation is to making love:
             : effective and always available but probably not your
             : first choice...

-- 
Sascha Wilde : VI is to EMACS as masturbation is to making love:
             : effective and always available but probably not your
             : first choice...

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacs & MAXPATHLEN

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> On Thu, Aug 04, 2005 at 01:13:48PM +0200, David Kastrup wrote:
>> Sascha Wilde <wilde@sha-bang.de> writes:
>> 
>> > On Thu, Aug 04, 2005 at 08:30:05AM +0200, David Kastrup wrote:
>> >> "Richard M. Stallman" <rms@gnu.org> writes:
>> >
>> >> >     Linux is not really a program in the usual sense.
>> >> >
>> >> > It is a program, in the usual sense of the word.
>> >> > You must have some unusual sense of the word in mind.
>> >> 
>> >> <URL:http://en.wikipedia.org/wiki/Operating_system>
>> >> <URL:http://en.wikipedia.org/wiki/Computer_program>
>> >
>> > Lets have a look:
>> >
>> >     Operating system
>> >     From Wikipedia, the free encyclopedia.
>> >
>> >     In computing, an operating system (OS) is the system software
>> >     [...]
> [...]
>> > ... and here we go, it's a "computer program" (what a surprise) --
>> > your second link.  :)
>> 
>> According to your reference interpreting skills, GNU/Linux would
>> count as just "a computer program", too.
>
> Well, not one, many -- but anyway just "computer programs".
>
> Yes, that is exactly my point, I think Richard is right: 
> Linux is just a program "in the usual sense".

But I was talking about GNU/Linux.  It seems you don't even get the
difference we are talking about.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs & MAXPATHLEN

[Alfred M. Szmidt]

GNU/Linux is indeed _a_ program.  Just like Emacs is _a_ program,
where Emacs has several modules (elisp files) that do different
things.  On GNU/Linux the "modules" would be files of a different form
(like ELF files).  A program is just a bunch of instructions stored on
some form of a medium.  So if Emacs is a program, GNU/Linux must be a
program, and vice versa.

Seriously, can you now all stop this silly discussion? :-)

Re: emacs & MAXPATHLEN

[Juanma Barranquero]

On 8/4/05, David Kastrup <dak@gnu.org> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:

> > Yes, that is exactly my point, I think Richard is right:
> > Linux is just a program "in the usual sense".
> 
> But I was talking about GNU/Linux.  It seems you don't even get the
> difference we are talking about.

[jumping in]

Perhaps in a parallel universe you were talking about GNU/Linux. In
this universe, you said:

> Linux is not really a program in the usual sense.

Richard retorted:

> It is a program, in the usual sense of the word.
> You must have some unusual sense of the word in mind.

And you countered:

> Looks more like a collection of services to me, somewhat like a library. 

So definitely you were talking (or at least, you were *writing*) about
Linux, not GNU/Linux. I cannot even begin to imagine how could you
define GNU/Linux as "a collection of services", or worse, "like a
library".

God knows I don't have the slightest intention of stopping this little
flamewar, but to my eyes, and I think most programmers', Linux is of
course a program "in the usual sense" even if it is an operating
system kernel too (both things not being mutually exclusive, of
course)...

-- 
                    /L/e/k/t/u

Re: emacs & MAXPATHLEN

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On 8/4/05, David Kastrup <dak@gnu.org> wrote:
>> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> > Yes, that is exactly my point, I think Richard is right:
>> > Linux is just a program "in the usual sense".
>> 
>> But I was talking about GNU/Linux.  It seems you don't even get the
>> difference we are talking about.
>
> [jumping in]
>
> Perhaps in a parallel universe you were talking about GNU/Linux. In
> this universe, you said:
>
>> Linux is not really a program in the usual sense.
>
> Richard retorted:
>
>> It is a program, in the usual sense of the word.
>> You must have some unusual sense of the word in mind.
>
> And you countered:
>
>> Looks more like a collection of services to me, somewhat like a
>> library.
>
> So definitely you were talking (or at least, you were *writing*)
> about Linux, not GNU/Linux.

That definitely was what the original argument was about.  But in my
reply to Sascha I pointed out to him that his way of applying the term
"a program" to Linux would fit GNU/Linux quite as well.  Which did not
really serve to render the view he claimed to support more plausible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs & MAXPATHLEN

[Juanma Barranquero]

On 8/4/05, David Kastrup <dak@gnu.org> wrote:

> But in my
> reply to Sascha I pointed out to him that his way of applying the term
> "a program" to Linux would fit GNU/Linux quite as well.  Which did not
> really serve to render the view he claimed to support more plausible.

Oh, I think yes, it does make it more plausible. I call Emacs "a
program", irrespective of whether it includes other, subservient
programs (like movemail, emacsclient, etc.). I don't think the
definition of "program" is as monolithic as you make it sound.

-- 
                    /L/e/k/t/u

Re: emacs & MAXPATHLEN

[Markus Gritsch]

David Kastrup wrote:
> 
> But I was talking about GNU/Linux.  It seems you don't even get the
> difference we are talking about.

Oh Boy, this discussion is getting so darn annoying, especially 
concerning the rudeness of some posts.  I would be quite happy so see 
the signal to noise ratio increase on this list back to its usual level.

Kind regards,
Markus