| Commit message (Collapse) | Author |
|---|
|
The native version of expandmeta allocates a buffer that may be
overrun for two reasons. First of all the size is 1 byte too small
but this is normally hidden because the minimum size is rounded
up to 2048 bytes. Secondly, if the directory level is deep enough,
any buffer can be overrun.
This patch fixes both problems by calling realloc when necessary.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Currently echocmd uses print_escape_str to do everything apart
from printing the spaces/newlines separating its arguments. This
patch moves the actual printing into print_escape_str as well
using the format parameter.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The commit d6c0e1e2ffbf7913ab69d51cc794d48d41c8fcb1 ("[BUILTIN]
Handle embedded NULs correctly in printf") caused a performance
regression in the echo built-in because every echo call now goes
through the printf %b slow path where the string is always printed
twice to ensure the space padding is correct in the presence of
NUL characters. In fact this regression applies to printf %b as
well.
This is easily fixed by making printf %b take the fast path when
no precision/field width modifiers are present.
This patch also changes the second strchurnul call to strspn which
generates slightly better code.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Harald van Dijk <harald@gigawatt.nl> wrote:
> On 22/03/2018 22:38, Martijn Dekker wrote:
>> Op 22-03-18 om 20:28 schreef Harald van Dijk:
>>> On 22/03/2018 03:40, Martijn Dekker wrote:
>>>> This patch fixes the bug that, given no positional parameters, unquoted
>>>> $@ and $* incorrectly generate one empty field (they should generate no
>>>> fields). Apparently that was a side effect of the above.
>>>
>>> This seems weird though. If you want to remove the recording of empty
>>> regions because they are pointless, then how does removing them fix a
>>> bug? Doesn't this show that empty regions do have an effect? Perhaps
>>> they're not supposed to have any effect, perhaps it's a specific
>>> combination of empty regions and something else that triggers some bug,
>>> and perhaps that combination can no longer occur with your patch.
>>
>> The latter is my guess, but I haven't had time to investigate it.
>
> Looking into it again:
>
> When IFS is set to an empty string, sepc is set to '\0' in varvalue().
> This then causes *quotedp to be set to true, meaning evalvar()'s quoted
> variable is turned on. quoted is then passed to recordregion() as the
> nulonly parameter.
>
> ifsp->nulonly has a bigger effect than merely selecting whether to use
> $IFS or whether to only split on null bytes: in ifsbreakup(), nulonly
> also causes string termination to be suppressed. That's correct: that
> special treatment is required to preserve empty fields in "$@"
> expansion. But it should *only* be used when $@ is quoted: ifsbreakup()
> takes nulonly from the last IFS region, even if it's empty, so having an
> additional zero-length region with nulonly enabled causes confusion.
>
> Passing quoted by value to varvalue() and not attempting to modify it
> should therefore, and in my quick testing does, also work to fix the
> original $@ bug.
You're right. The proper fix to this is to ensure that nulonly
is not set in varvalue for $*. It should only be set for $@ when
it's inside double quotes.
In fact there is another bug while we're playing with $@/$*.
When IFS is set to a non-whitespace character such as :, $*
outside quotes won't remove empty fields as it should.
This patch fixes both problems.
Reported-by: Martijn Dekker <martijn@inlv.org>
Suggested-by: Harald van Dijk <harald@gigawatt.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
On Fri, Mar 16, 2018 at 11:27:22AM +0800, Herbert Xu wrote:
> On Thu, Mar 15, 2018 at 10:49:15PM +0100, Harald van Dijk wrote:
> >
> > Okay, it can be trivially modified to something that does work in other
> > shells (even if it were actually executed), but gets rejected at parse time
> > by dash:
> >
> > if false; then
> > : ${$+
> > }
> > fi
>
> That's just a bug in dash's parser with ${} in general, because
> it bombs out without the if clause too:
>
> : ${$+
> }
This patch fixes the parsing of newlines with parameter substitution.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
On Sun, Mar 04, 2018 at 12:44:59PM +0100, Harald van Dijk wrote:
>
> command: set -- a ""; space=" "; printf "<%s>" "$@"$space
> bash: <a><>
> dash 0.5.8: <a>< >
> dash 0.5.9.1: <a>< >
> dash patched: <a><>
This is actually composed of two bugs. First of all our tracking
of quotemark is wrong so anything after "$@" becomes quoted. Once
we fix that then the problem is that the first space character
after "$@" is not recognised as an IFS.
This patch fixes both.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
This reverts commit 7bb413255368e94395237d789f522891093c5774.
The commit breaks printf with more than argument.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|