Richard M. Stallman [EMAIL PROTECTED] 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
On Thu, Aug 04, 2005 at 08:30:05AM +0200, David Kastrup wrote:
Richard M. Stallman [EMAIL PROTECTED] 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.
Sascha Wilde [EMAIL PROTECTED] writes:
On Thu, Aug 04, 2005 at 08:30:05AM +0200, David Kastrup wrote:
Richard M. Stallman [EMAIL PROTECTED] 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
On Thu, Aug 04, 2005 at 01:13:48PM +0200, David Kastrup wrote:
Sascha Wilde [EMAIL PROTECTED] writes:
On Thu, Aug 04, 2005 at 08:30:05AM +0200, David Kastrup wrote:
Richard M. Stallman [EMAIL PROTECTED] writes:
Linux is not really a program in the usual sense.
It is a
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
On 8/4/05, David Kastrup [EMAIL PROTECTED] wrote:
Sascha Wilde [EMAIL PROTECTED] 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
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 8/4/05, David Kastrup [EMAIL PROTECTED] 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
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.
___
Emacs-devel mailing list
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
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.
Richard M. Stallman [EMAIL PROTECTED] 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
Richard M. Stallman [EMAIL PROTECTED] 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:
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?
___
Emacs-devel
Richard M. Stallman [EMAIL PROTECTED] 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.
Richard M. Stallman [EMAIL PROTECTED] 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
From: Giuseppe Scrivano [EMAIL PROTECTED]
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
+#else
+ {
+int buf_size = 2;
+buf = xmalloc (buf_size);
+for(;;)
+ {
+if(getcwd (buf, buf_size) == 0)
+ {
+if(errno == ERANGE)
+ {
+buf_size *= 2;
+buf =
--- src/buffer.c.old 2005-07-28 19:14:42.0 +0200
+++ src/buffer.c 2005-07-30 03:20:36.0 +0200
...
+ {
+int buf_size = 2;
+buf = xmalloc (buf_size);
+for(;;)
+ {
+if(getcwd (buf, buf_size) == 0)
+
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 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'
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
___
Emacs-devel mailing list
Emacs-devel@gnu.org
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)
Well.. this code seems cleaner than the older one and without memory leaks :)
Alfred M\. Szmidt [EMAIL PROTECTED] 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. :-)
This new version should follow all your hints:
--- configure.in.old2005-07-29 18:14:02.0 +0200
+++ configure.in2005-07-29 18:19:26.0 +0200
@@ -2414,7 +2414,7 @@
AC_CHECK_HEADERS(maillock.h)
AC_CHECK_FUNCS(gethostname getdomainname dup2 \
-rename closedir mkdir
Alfred M. Szmidt [EMAIL PROTECTED] 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);
??? 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...
___
Emacs-devel mailing list
Emacs-devel@gnu.org
Could you make a single subroutine and call it from both
buffer.c and xsmfns.c?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Richard M. Stallman [EMAIL PROTECTED] 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.old2005-07-29
Eli Zaretskii [EMAIL PROTECTED] 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
From: Andreas Schwab [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
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
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
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:
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
--- src/buffer.c.old2005-07-28 19:14:42.0 +0200
+++ src/buffer.c2005-07-29 02:21:03.0 +0200
@@ -5146,14 +5146,47 @@
stat (., dotstat) == 0
dotstat.st_ino == pwdstat.st_ino
dotstat.st_dev == pwdstat.st_dev
- strlen (pwd)
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.
+
From: Giuseppe Scrivano [EMAIL PROTECTED]
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
Richard M. Stallman [EMAIL PROTECTED] 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
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
+ 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
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
Richard M. Stallman [EMAIL PROTECTED] 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
42 matches
Mail list logo
