[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nano-devel] Patch to files.c

From: David Benbennick
Subject: [Nano-devel] Patch to files.c
Date: Tue, 26 Mar 2002 06:14:03 -0500 (EST)

Here is another seg fault fix.  It includes the patch I sent at 3:14.  
Again with files.c,v 1.155, do
        nano -z
        ^R     (Read File)
        ^X     (Execute Command)
Of course it freezes.  Now type ^Z to stop nano, then fg from the
shell to resume nano.  You get
        nano -z
        stdin: Interrupted system call
        Segmentation fault
The attached patch fixes the seg fault.  The problem was that read_byte()
was reporting it had read 1 byte even when the read() had an error.

Note that the same seg fault happens for any I/O error.  For example,
doing "nano /proc/<certain-PIDs>/mem" caused a seg fault for some PIDs,
and doesn't with the patch.

I also changed "char input[2];" to "char input" in read_file,
since only the first character of that array was ever used.

Finally, in open_pipe() I replaced
The second argument to execl is supposed to be the executable file name,
not the whole path.

There are two issues here that still could be fixed.

* In files.c:read_byte(), there is a call to perror.  perror is
used nowhere else in nano.  I guess it should be replaced by
something like
        statusbar(_("Error reading file: %s"), strerror(errno));
But there are plenty of other system calls, such as execl, wait, dup2,
close (and others), for which we should report errors to stderr and not to
the status bar (because the user wouldn't have any clue why dup2 is
complaining of too many file descriptors).  Thus, there should be a
generic function, call it nperror, that handles the necessary Curses
calls.  Any opinions on that?

* Perhaps we can fix the silly bash-freezing thing.  Here are two

First idea: Change the code so that read_file() always reports I/O errors.  
Then make open_pipe() kill the forked process if there is a read error.  
Then if you freeze nano by running bash, you can simply ^Z then fg to get
it back.  Of course, this only works if you use "nano -z".

Second idea: before doing "wait(&fork_status);" in open_pipe(), change the
SIGINT action from SIG_IGN to a routine that kills the fork.  Thus, typing
^C will unfreeze nano in that case.


Attachment: 26mar05:50.diff
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]