Dash parser fixes

[tucak]

This is for handling cases like ${}, ${,}, ${+}, etc. Without this, they would end up in an endless mutual recursion of shim.parse_arg and shim.arg_char, ending with a stack overflow:

Fatal error: exception Stack overflow
Raised by primitive operation at file "shim.ml", line 277, characters 22-34
Called from file "shim.ml", line 253, characters 20-54
Called from file "shim.ml", line 305, characters 25-67
Called from file "shim.ml", line 305, characters 25-67

...repeating endlessly.

With this patch, the output is:

smoosh: bad substitution

[tucak]

I am putting this here, otherwise there would be merge conflicts.

Another crash caused by miscommunication between Smoosh and Dash. This time a buffer overflow.

Reproducer:

force="echo 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
AAAAAAAAAAAAA' >/dev/null"

eval "eval ${force}"

eval "${force}"

Why does it fail?

In Dash, the order of memory operations when executing eval is:

• sstrdup
• setinputstring
• setstackmark
• do whatever needs to be done...
• popstackmark
• popfile
• stunalloc

In Smoosh, one of the pieces was missing:

• sstrdup
• setinputstring
• setstackmark
• do whatever needs to be done...
• popfile
• stunalloc

The problem with this is that in Dash, stack blocks can only be deallocated using popstackmark. stunalloc assumes that the string being "unallocated" is in the currently active stack block, and just sets the next free byte to be the beginning of the string. This can lead to buffer overflows.

After the inner eval, the stack blocks look like the following:

                               stacknxt       sstrend
                                  v              v
    prev  .--------------.  prev  .--------------.
  <-------|  outer eval  |<-------|  inner eval  |
          '--------------'        '--------------'

Where stacknxt points to the next free byte, and sstrend to the end of the allocation. The active stack block is the one belonging to inner eval.

When the outer eval is done, the situation turns into the following:

       stacknxt                               sstrend
          v                                      v
    prev  .--------------.  prev  .--------------.
  <-------|  outer eval  |<-------|  inner eval  |
          '--------------'        '--------------'

The block of inner eval is still the active block, but the next free byte is now pointing to the beginning of outer eval. Everything between the two is viewed as free memory by Dash, and the next eval string, if longer than the original outer eval string, will happily write beyond the area allocated for outer eval.

Popping the stackmark like Dash does fixes this issue.

[mgree]

Whew---I'm finally getting to these! I'm sorry to have taken so long.

Travis is being weird (stuck in an old .travis.yml file), but the tests look good here. Thank you!!!!!