`recurse/0` already handles traversing objects and arrays, so it is more
consistent to use that.
For `paths/1` it is easier to use the actual value returned by
`recurse` instead of querying that value with `getpath/1` afterwards.
* bugfix: comments were incorrectly being terminated by CR; for example
jq -n $'1 #foo\r'
fails to compile because the CR character terminates the comment, and
CR is not a valid character in jq syntax.
* improvement: comments fully support Tcl-style line continuation.
Previously this was only "supported" in `-f' scripts, whose first line
starts with "#!", and second line starts with # and ends with \, only
for the comment on the second line, only for one extra line.
* man: document comment syntax, which was previously undocumented.
* tests: add regression tests for the bugfix, and some tests for line
continuation in comments.
Otherwise `AGRS` and `program_arguments` remain allocated/unfreed in the
early (extremely unlikely) pledge(2) failure case.
Move their allocation before jq_init(), the first case of jumping to
`out` where they are cleaned up, where it also seems to logically fit
better than above between function entry, locale setup and OpenBSD
specific pledge.
Use pledge(2)[0] to limit jq(1) to reading files.
It does not change files and only writes to standard output/error.
It never deals with TTY, network, process management or other subsystems.
This is to reduce jq's attack surface and potential damage.
OpenBSD is carrying a local patch[1] in its official jq port/package
since 2016. An improved version:
- drop no longer needed "getpw" promise
f1c4947 "Avoid getpwuid for static linking" removed getpwuid(3) usage
- pledge before jq_init() to simplify the error path
- use perror(3) to print errno(2)
No behaviour change in tests or real world usage observed on
OpenBSD/amd64 7.4.
0: https://man.openbsd.org/pledge.2
1: https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/textproc/jq/patches/patch-main_c
This reverts commit 0e70f7a57e.
There is no reason to revert this change.
In #2922, I only disagreed with the commit message suggesting that
LC_CTYPE=C od -t c is equivalent to od -c
The only documented differences are that -tc is required to be
influenced by -N and -j, while -c is not, and that -c is required to
only support a subset of the backslash sequences that -tc should
support.
jq previously only allowed passing the inline script before -- (as if
they were options) even though one would expect the inline script to be
a positional argument.
Since jq previously also refused to run with a usage error if the script
was passed after -- (It was not assuming . as script as it does when
no arguments are passed), and positional arguments are allowed before --
and even before other options, it should not be a breaking change to
change that weird behaviour, and allow the script to appear after --.
It also simplifies the option parsing code a bunch.
Fixes#2918
In process there is a suspicious options |= EXIT_STATUS_EXACT that
is run when the jq script is terminated by halt, or halt_error.
That line of code acutally does nothing because options is a local
argument variable, and is not passed as a pointer. It was probably meant
to be a *options |= EXIT_STATUS_EXACT with the options argument
passed as a int*.
In any case, we do not want to run the code in main() that was supposed
to run if EXIT_STATUS_EXACT is set (but didn't since it is never added
to options); as far as I can tell, we only want to run that code when
the --exit-status/-e option is passed.
So I removed EXIT_STATUS_EXACT completely, and the useless assignment,
instead of fixing it since it was not used for anything else.
Useless assignment detected by clang-tidy.
A very large program can cause these leaks:
==758838== 7,820 (16 direct, 7,804 indirect) bytes in 2 blocks are definitely lost in loss record 17 of 28
==758838== at 0x4848A23: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==758838== by 0x125D30: jv_mem_calloc (jv_alloc.c:153)
==758838== by 0x162ADE: compile (compile.c:1286)
==758838== by 0x162D4B: compile (compile.c:1304)
==758838== by 0x163697: block_compile (compile.c:1381)
==758838== by 0x11B5CA: jq_compile_args (execute.c:1245)
==758838== by 0x115E20: main (main.c:691)
==758838==
==758838== 1,674,694 (103,576 direct, 1,571,118 indirect) bytes in 1,177 blocks are definitely lost in loss record 28 of 28
==758838== at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==758838== by 0x125CD0: jv_mem_alloc (jv_alloc.c:141)
==758838== by 0x162B19: compile (compile.c:1289)
==758838== by 0x163697: block_compile (compile.c:1381)
==758838== by 0x11B5CA: jq_compile_args (execute.c:1245)
==758838== by 0x115E20: main (main.c:691)
This commit fixes that.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61349
For the jq_state used by the jq utility, the JQ_LIBRARY_PATH attribute
will always be set, but, in general, it is possible that it might not
be.
If it is not set, jq_get_lib_dirs() will return jv_invalid().
That is not good, because some code in linker.c expects it to always
returns an array.
This patch makes jq_get_lib_dirs() return an empty array if
JQ_LIBRARY_PATH is not set to prevent problems.
This issue made OSS fuzz trigger failed assertions every time it tried
to compile a script that uses "include".
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61796
David Korczynski