Op 07-03-18 om 06:26 schreef Herbert Xu:
> Martijn Dekker wrote:
>>
>>> Since base is always a constant 0 or a constant 10, never a
>>> user-provided value, the only error that strtoimax will ever report on
>>> glibc systems is ERANGE. Checking only ERANGE therefore preserves the
>>> glibc behavio
Op 06-03-18 om 09:19 schreef Herbert Xu:
> On Thu, Jun 22, 2017 at 10:30:02AM +0200, Petr Skočík wrote:
>> would you be willing to pull something like this?
[...]
>> I could use greater resolution in `test -nt` / `test -ot`, and st_mtim
>> field is standardized under POSIX.1-2008 (or so stat(2) say
On Sun, Mar 04, 2018 at 10:29:25PM +0100, Harald van Dijk wrote:
>
> Another pre-existing dash parsing bug that I encountered now is $(( ( $(( 1
> )) ) )). This should expand to 1, but gives a hard error in dash, again due
> to the non-recursive nature of dash's parser. A small generalisation of wh
Op 07-03-18 om 15:46 schreef Martijn Dekker:
> Op 06-03-18 om 09:19 schreef Herbert Xu:
>> On Thu, Jun 22, 2017 at 10:30:02AM +0200, Petr Skočík wrote:
>>> would you be willing to pull something like this?
> [...]
>>> I could use greater resolution in `test -nt` / `test -ot`, and st_mtim
>>> field
On 3/7/18 7:51 AM, Herbert Xu wrote:
On Wed, Mar 07, 2018 at 07:49:16AM +0100, Harald van Dijk wrote:
This was wrong in the original patch, but I'm not seeing it in the updated
patch that you replied to. When parsing a heredoc where part of delimiter is
quoted, syntax==SQSYNTAX. Since the calls
On 3/7/18 5:29 PM, Herbert Xu wrote:
On Sun, Mar 04, 2018 at 10:29:25PM +0100, Harald van Dijk wrote:
Another pre-existing dash parsing bug that I encountered now is $(( ( $(( 1
)) ) )). This should expand to 1, but gives a hard error in dash, again due
to the non-recursive nature of dash's par
Op 07-03-18 om 16:29 schreef Herbert Xu:
> I also didn't quite like the idea of scanning the string backwards
> to find the previous syntax. So here is my attempt at the recursive
> parsing using alloca.
This version introduces a parsing bug:
$ src/dash -c 'x=0; x=$((${x}+1))'
src/dash: 1: Synt
On 3/7/18 8:04 PM, Harald van Dijk wrote:
On 3/7/18 5:29 PM, Herbert Xu wrote:
On Sun, Mar 04, 2018 at 10:29:25PM +0100, Harald van Dijk wrote:
Another pre-existing dash parsing bug that I encountered now is $(( (
$(( 1
)) ) )). This should expand to 1, but gives a hard error in dash,
again
On Wed, Mar 07, 2018 at 07:19:56PM +0100, Harald van Dijk wrote:
> On 3/7/18 7:51 AM, Herbert Xu wrote:
> >On Wed, Mar 07, 2018 at 07:49:16AM +0100, Harald van Dijk wrote:
> >>
> >>This was wrong in the original patch, but I'm not seeing it in the updated
> >>patch that you replied to. When parsing
On 3/8/18 7:30 AM, Herbert Xu wrote:
Could you please resend these patches as two separate emails please?
Patchwork cannot handle two patches in one email:
https://patchwork.kernel.org/patch/10264661/
Ah, didn't realise that. I'll keep that in mind for future mails.
Actually, I'll wit
On Wed, Mar 07, 2018 at 08:25:07PM +, Martijn Dekker wrote:
>
> This version introduces a parsing bug:
>
> $ src/dash -c 'x=0; x=$((${x}+1))'
> src/dash: 1: Syntax error: Unterminated quoted string
>
> It is triggered by the ${x} (with braces) within an arithmetic expression.
Thanks for test
On Thu, Mar 08, 2018 at 01:40:32AM +0100, Harald van Dijk wrote:
>
> If the syntax stack is to be stored on the actual stack, then real recursion
> could be used instead, as attached. I tried to avoid recursion for the cases
> that unpatched dash already handled properly.
It does look a lot simple
12 matches
Mail list logo