It does not matter much since they most likely just get multiplied
together, but some compilers would complain about this if these were
calls to calloc.
If using libjq from C++ it would be nice to not need to do this at the
import site, so just extern "C" to the public headers for libjq
Signed-off-by: Tyler Rockwood <rockwood@redpanda.com>
`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
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
Although #2839 fixed the overflow of exponent subtraction,
there still is possibility of overflow in the `D2U` macro.
This patch fixes the overflow in the `D2U` macro, and also
truncates the maximum digits to `DEC_MAX_DIGITS`.
The decNumber library subtracts the exponents of two numbers,
we make sure to limit the number of digits not to make it overflows.
Since the maximum adjusted exponent is `emax` and the minimum is
`emin - digits + 1`, we follow `emax - (emin - digits + 1) <= INT32_MAX`.
This reuses the existing `block_list_funcs` capability and adds an extra field on the `modulemeta` output, called `defs`, containing that list of functions.
* Build windows 64bit binary using UCRT64
Is the default and recommended msystem setting. Will produce
binaries that are compatible with windows 10 and later.
Also run tests for 32bit build.
Related to #2831
* Use jq -b in tests/shtest
* Add Windows strptime
* Make Windows-optional tests not run on Windows again
---------
Co-authored-by: Nicolas Williams <nico@cryptonector.com>
This patch removes the weird behaviour of jv_invalid_with_msg(jv_null())
that returns jv_invalid() (i.e. empty), instead of a boxed jv_null().
The previous behaviour of null|error was obviously unintentional, and
allowing is jv_invalid_with_msg() to return values on which you can't
call jv_invalid_get_msg() is only error prone.
This patch exports all the binary operator builtins functions from
builtin.c and uses them for constant folding in the parser, allowing
constant folding to work will all kinds and combinations of constants.
Now string*number, $ARGS+$ARGS, string/string, etc will also be
constant folded and the implementation of constant folded operators and
runtime operators will be the same.
And thanks to the new ERRORK bytecode operation, errors are constant
folded too! (e.g. 1 / 0 [] * {} etc)
Use a StringStart component that is either FORMAT QQSTRING_START or
QQSTRING_START instead of having two similar rules for String.
This is simpler and avoids having to use an untyped mid-rule action
component to copy FORMAT at the top of the stack before QQString, and
having to use jv_free($<literal>3) instead of jv_free($1) just to make
bison not complain about the "unused" mid-rule component.
Previously constant folding of zero division (e.x. 1/0) produces a
compile error. This was incorrectly implemented by checking if the
division result is infinite, so produces wrong results compared to the
query where no constant folding is processed (e.x. 1e308/0.1). This
patch delays the operation when the divisor is zero. This makes the
results more consistent, but changes the exit code on zero division from
3 to 5. Also 0/0 now produces the zero division error, not NaN.
This patch also fixes the modulo operation. Previously constant folding
logic does not take care of the % operator, but now it folds if the both
dividend and divisor are safe numbers to cast to the integer type, and
the divisor is not zero. This patch also fixes some code that relies on
undefined cast behaviors in C. The modulo operation produces NaN if
either the dividend or divisor is NaN.
You only need to specify the return type in a function pointer
declaration in C.
If you use () in the declaration, the function pointer can be called
with any arguments, and the type of the arguments is decided for each
function call based on the types of the arguments used for the call.
(To declare a function pointer for a function with no arguments, you use
`(void)'.)
Since all the cfunction structs have a fptr that points to a functions
that return jv, not void, we can we can just declare cfunction.fptr as
jv (*)() and avoid having those annoying and technically not C-standard
compliant casts everywhere.
Emanuele Torre