| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
Now that we're marking file descriptors as CLOEXEC in savefd, we no longer
need to close them on exec or in setinputfd.
|
| |
|
|
|
|
|
| |
There are two kinds of users to copyfd, those that want to copy an fd to
an exact value and those that want to move an fd to a value >= 10. The
former can simply use dup2 directly while the latter share a lot of common
code that now constitutes savefd.
|
| |
|
|
|
| |
No caller of copyfd need to ignore EMFILE so we can remove the special
case and just let it call sh_error on any error.
|
| |
|
|
|
|
|
|
|
| |
The existing scheme of using the native char for syntax array indicies
makes cross-compiling difficult. Therefore it makes sense to choose
one specific sign for everyone.
Since signed chars are native to most platforms and i386, it makes more
sense to use that if we are to choose one type for everyone.
|
| |
|
|
|
|
|
|
|
|
|
| |
This change updates the BSD licence to the three-clause version since
NetBSD has already done so. This makes dash GPL-compatible.
It also adds Christos Zoulas (NetBSD ash maintainer) to the COPYING file.
I've added "copyright by Herbert Xu" to most files.
Finally all CVS IDs and inclusion of sys/cdefs.h have been removed.
The latter is needed for support of klibc.
|
| |
|
|
|
|
|
| |
Added unlikely markers.
Reduced switch coverage.
Removed p since we now erase NULs as soon as we see them.
Use more to store parselleft.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Sun, Sep 25, 2005 at 07:50:54PM +0000, Gerrit Pape wrote:
> On Sat, Sep 03, 2005 at 02:56:00PM +0200, Martin Dickopp wrote:
> > When analysing the bug I came to the following conclusion: The loop
> > beginning at input.c:302 overwrites a single input line with itself,
> > skipping NUL characters. Therefore, after the loop the line buffer
> > has less characters than originally read if and only if the input line
> > contains NUL characters.
>
> yes. Thanks a lot for the details and patch.
>
> > The pointer that is used to read from the buffer, 'parsenextc' (cf.
> > input.h:66), is also used as the beginning of the next line in
> > input.c:296. This fails if the buffer contains less characters
> > than originally read into it due to NUL characters.
> >
> > The proposed patch (attached) keeps track of the number of skipped
> > characters and advances 'parsenextc' accordingly before processing
> > the next input line.
>
> Hi Herbert, please see
> http://bugs.debian.org/317516
Instead of moving the characters in the loop, we will do memmove every
time we see a NUL character. This hurts if there are a lot of NUL
characters, but should be a win in normal situations.
|
| | |
|
| | |
|
| |
|