Emanuele Torre 0b82b3841b builtin.c: typecheck builtin cfunctions in function_list
In C23 (default C standard used by GCC 15),  jv (*fptr)();  has become
equivalent to  jv (*fptr)(void);  so we can no longer assign builtin
implemenations directly to the fptr member of cfunctions without
generating a compile error.

Since there does not seem to be any straight-forward way to tell
autoconf to force the compiler to use C99 short of explicitly adding
-std=c99 to CFLAGS, it is probably a cleaner solution to just make the
code C23 compatible.

A possible solution could have been to just redeclare  cfunction.fptr
as void*, but then the functions' return type would not have been type
checked (e.g. if you tried to add a {printf, "printf", 2}, where printf
is a function that does not return jv, the compiler wouldn't have
complained.)
We were already not typechecking the arguments of the functions, so e.g.
  {binop_plus, "_plus", 3},  /* instead of {f_plus, "_plus, 3},       */
  {f_setpath, "setpath", 4}, /* instead of {f_setpath, "setpath", 3}, */
compile without errors despite not having the correct prototype.

So I thought of instead improving the situation by redefining
cfunction.fptr as a union of function pointers with the prototypes that
the jq bytecode interpreter can call, and use a macro to add the builtin
functions to function_list using to the arity argument to assign the
implementation function to the appropriate union member.

Now the code won't compile if the wrong arity, or an arity not supported
by the bytecode interpreter (>5 = 1input+4arguments), or a prototype not
jallable by the bytecode interpreter (e.g. binop_plus that doesn't
expect a  jq_state*  argument).

Also, the code now compiles with gcc -std=c23.

Fixes #3206
2024-12-01 11:49:44 +01:00
2018-10-12 16:23:09 -04:00
2023-07-16 00:02:46 -05:00
2023-12-13 20:52:03 +01:00
2017-02-18 21:34:26 -05:00
2023-06-13 20:01:20 +09:00
2024-02-06 14:51:46 +01:00
2016-02-24 00:39:56 -08:00
2024-08-22 08:07:24 +09:00
2024-09-13 18:30:49 +09:00
2023-06-19 00:07:29 -05:00

jq

jq is a lightweight and flexible command-line JSON processor akin to sed,awk,grep, and friends for JSON data. It's written in portable C and has zero runtime dependencies, allowing you to easily slice, filter, map, and transform structured data.

Documentation

Installation

Prebuilt Binaries

Download the latest releases from the GitHub release page.

Docker Image

Pull the jq image to start quickly with Docker.

Run with Docker

Example: Extracting the version from a package.json file
docker run --rm -i ghcr.io/jqlang/jq:latest < package.json '.version'
Example: Extracting the version from a package.json file with a mounted volume
docker run --rm -i -v "$PWD:$PWD" -w "$PWD" ghcr.io/jqlang/jq:latest '.version' package.json

Building from source

Dependencies

  • libtool
  • make
  • automake
  • autoconf

Instructions

git submodule update --init    # if building from git to get oniguruma
autoreconf -i                  # if building from git
./configure --with-oniguruma=builtin
make clean                     # if upgrading from a version previously built from source
make -j8
make check
sudo make install

Build a statically linked version:

make LDFLAGS=-all-static

If you're not using the latest git version but instead building a released tarball (available on the release page), skip the autoreconf step, and flex or bison won't be needed.

Cross-Compilation

For details on cross-compilation, check out the GitHub Actions file and the cross-compilation wiki page.

Community & Support

License

jq is released under the MIT License. jq's documentation is licensed under the Creative Commons CC BY 3.0. jq uses parts of the open source C library "decNumber", which is distributed under ICU License

S
Description
No description provided
Readme BSD-2-Clause, MIT
24 MiB
0 Stars 1 Watchers 0 Forks
Languages
C 78.7%
M4 6.4%
Shell 6.3%
Yacc 3.2%
jq 1.5%
Other 3.9%