Re: [PATCH] parser: preserve characters on heap in backquote parsing

Ron Yorston wrote: > > Sure, but the same problem existing in other places isn't a reason not > to fix it here. If this were a real script then I might agree with you. But given that this came from a deliberately crafted script to breach the 8MB size limit, it would be pointless to fix it in

eval: Use sh_warnx instead of warnx

Antonio Ospite wrote: > > BTW a new warning was introduced by commit 8e43729 (eval: Report I/O > error on stdout, 2018-09-07): > > CC eval.o > eval.c: In function ‘evalbltin’: > eval.c:956:3: warning: implicit declaration of function ‘warnx’; did you mean > ‘sh_warnx’?

Re: [PATCH] parser: preserve characters on heap in backquote parsing

Herbert Xu wrote: >Sorry, but this is not the only place where dash relies on alloca. >So you're bound to run into this problem again if you have a script >that attempts to push dash to use more than 8MB in places like this. Sure, but the same problem existing in other places isn't a reason not

Re: [PATCH 0/5] Build system updates and gcc warnings fixes

On Sat, 27 Oct 2018 15:35:11 +0200 Antonio Ospite wrote: > On Tue, 16 Oct 2018 18:42:15 +0200 > Antonio Ospite wrote: > > > Hi, > > > > here are some build system updates and some fixes for compilation > > warnings with Gcc. > > > > After this patchset, compilation with Gcc is nice and

Re: [PATCH] parser: preserve characters on heap in backquote parsing

Ron Yorston wrote: > This bug report for BusyBox ash also applies to dash: > > https://bugs.busybox.net/show_bug.cgi?id=9246 > > With an 8MB stack the test case results in a segfault. > > Instead of using alloca() to preserve characters keep them on the > memalloc stack. With this change

system: Disable gcc warning on sigsetmask

Jilles Tjoelker wrote: > > The git history starts (in 2005) after HAVE_SIGSETMASK was added, but I > expect it was done this way to save a few bytes in the executable. With > ProPolice, the effect may be a bit more since a local variable of type > sigset_t often contains an array and may cause

parser: Do not push token back before parseheredoc

Sorry for the repost, I'm trying to get this into patchwork. ---8<--- When we read the first token in list() we use peektoken instead of readtoken as the following code needs to use the same token again. However, this is wrong when we're in a here-document as it will clobber the saved token

[PATCH] expand: Eat closing brace for length parameter expansion

Apologies for the reposts, but I'm having problems making this get into patchwork. ---8<--- When we are doing VSLENGTH expansion, the closing brace is currently not removed in evalvar. This causes the caller argstr to terminate prematurely as it would interpret the closing brace as one that

Re: [PATCH] Add the seq builtin and improve some things in printf.c

Devin Hussey wrote: > From: Devin Hussey > > I added the seq builtin. > > usage: seq [-w] [-f format] [-s string] [-t string] [first [incr]] last > > Some notes: >- 100% from scratch, aside from the small num_width algorithm I took from > StackOverflow and credited accordingly. >

Re: Command substitution in here-documents

On Fri, Aug 17, 2018 at 09:08:35PM +0800, Herbert Xu wrote: > Ron Yorston wrote: > > I've been continuing to worry about this. > > > > In the old code (prior to commit 7c245aa) the TNL token that was > > detected in list() had actually been read. The current code uses > > peektoken(). > > > >

eval: Use the correct expansion mode for fd redirection

It has been reported that echo test >&$EMPTY_VARIABLE causes dash to segfault. This is a symptom of the bigger problem that dash tries to perform pathname expansion as well as field splitting on the word after >& and <&. This is wrong and this patch fixes it to use the same expansions