Skip to content

Bug with nested path and variable-style parameters #186

Closed
wader/fq
#392
@thaliaarchi

Description

I wanted to do performance and feature-coverage comparisons between jq and gojq using my wsjq Whitespace interpreter, which is considerably complex for a jq program (and overcomes the limitations of your jq Brainfuck interpreter). However, in the process, I uncovered a bug in gojq. Here's an example, reduced from various instructions in interpret_step:

def assert($cond; msg): if $cond then . else msg | halt_error end;
def at($n): assert(.stack|length > $n; "stack underflow") | .stack[-$n-1];
def top: at(0);

{ stack: [1, 2, 3] } |
top += top
$ jq -ncf minimal.jq
{"stack":[1,2,6]}
$ gojq -nf minimal.jq
gojq: invalid path against: object ({"stack":[1,2,3]})

If any of one these changes are made to the example program, it will run without error:

  • Change the parameter from a filter to a variable: $cond -> cond
  • Desugar the parameter filter: def assert(cond; msg): cond as $cond | … (the jq docs imply that this is equivalent)
  • Inline the call to assert/2 in at/1
  • Use bare array instead of in an object: { stack: [1, 2, 3] } and .stack -> [1, 2, 3] and .

So, the problem appears to be caused by a nested path generated by a filter that uses variable-style parameters.

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions