summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)AuthorFilesLines
2024-04-10Tests: added $request_uri tests with proxyAndrei Zeliankou1-1/+100
This patch consist of 3 tests: 1. Ensure that $request_uri won't change while proxying the request. 2. Same as 1, but modifying the request using the "rewrite" directive. 3. Same as 2, but with rewrite containing a percent-encoded string.
2024-04-10Docs: njs (lowercase) is more preferred way to mentionAndrei Zeliankou2-9/+9
2024-04-10njs (lowercase) is more preferred way to mentionAndrei Zeliankou3-5/+5
2024-04-09Wasm-wc: Bump the h2 crate from 0.4.2 to 0.4.4dependabot[bot]1-2/+2
Bumps h2 <https://github.com/hyperium/h2> from 0.4.2 to 0.4.4. Limit number of CONTINUATION frames for misbehaving connections. Link: Changelog <https://github.com/hyperium/h2/blob/master/CHANGELOG.md> Link: Commits <https://github.com/hyperium/h2/compare/v0.4.2...v0.4.4> Signed-off-by: dependabot[bot] <support@github.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> [ Tweaked commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-14Wasm-wc: Fix application restartsAndrew Clayton1-3/+12
Liam reported a problem when trying to restart wasm-wasi-component based applications using the /control/applications/APPLICATION_NAME/restart endpoint. The application would become unresponsive. What was happening was the old application process(es) weren't exit(3)ing and so while we were starting new application processes, the old ones were still hanging around in a non-functioning state. When we are terminating an application it must call exit(3). So that's what we do. We use the return value of nxt_unit_run() as the exit status. Due to exit(3)ing we also need to now explicitly handle the return on error case. Reported-by: Liam Crilly <liam@nginx.com> Fixes: 20ada4b5c ("Wasm-wc: Core of initial Wasm component model language module support") Closes: https://github.com/nginx/unit/issues/1179 Tested-by: Liam Crilly <liam@nginx.com> Tested-by: Danielle De Leo <d.deleo@f5.com> Co-developed-by: Dan Callahan <d.callahan@f5.com> Signed-off-by: Dan Callahan <d.callahan@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-14Rebuild wasm-wasi-component when any of its dependencies changeAndrew Clayton1-1/+8
Have cargo run if for example src/wasm-wasi-component/src/lib.rs is changed, or any of the other files that should perhaps trigger a rebuild. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-13Build with -std=gnu11 (C11 with GNU extensions)Alejandro Colomar1-2/+3
Currently Unit doesn't specify any specific C standard for compiling and will thus be compiled under whatever the compiler happens to default to. Current releases of GCC and Clang (13.x & 17.x respectively at the time of writing) default to gnu17 (C17 + GNU extensions). Our oldest still-supported system is RHEL/CentOS 7, that comes with GCC 4.8.5 which defaults to gnu90. Up until now this hasn't really been an issue and we have been able to use some C99 features that are implemented as GNU extensions in older compilers, e.g - designated initializers - flexible array members - trailing comma in enum declaration (compiles with -std=c89, warns with -std=c89 -pedantic) - snprintf(3) - long long (well we test for it but don't actually use it) - bool / stdbool.h - variadic macros However there are a couple of C99 features that aren't GNU extensions that would be handy to be able to use, i.e - The ability to declare variables inside for () loops, e.g for (int i = 0; ...; ...) - C99 inline functions (not to be confused with what's available with -std=gnu89). However, if we are going to switch up to C99, then perhaps we should just leap frog to C11 instead (the Linux Kernel did in fact make the switch from gnu89 to gnu11 in March '22). C17 is perhaps still a little new and is really just C11 + errata. GCC 4.8 as in RHEL 7 has *some* support for C11, so while we can make full use of C99, we couldn't yet make full use of C11, However RHEL 7 is EOL on June 30th 2024, after which we will no longer have that restriction and in the meantime we can restrict ourselves to the supported set of features (or implement fallbacks where appropriate). It can only be a benefit that we would be compiling Unit consistently under the same language standard. This will also help give the impression that Unit is a modern C code base. It is also worth noting the following regarding GCC "A version with corrections integrated was prepared in 2017 and published in 2018 as ISO/IEC 9899:2018; it is known as C17 and is supported with -std=c17 or -std=iso9899:2017; the corrections are also applied with - std=c11, and the only difference between the options is the value of STDC_VERSION." Suggested-by: Andrew Clayton <a.clayton@nginx.com> Acked-by: Andrew Clayton <a.clayton@nginx.com> [ Andrew wrote the commit message ] Signed-off-by: Alejandro Colomar <alx@kernel.org> Link: <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8c07082a810fbb9db303a2b66b66b8d7e588b53> Link: <https://www.ibm.com/blog/announcement/ibm-is-announcing-red-hat-enterprise-linux-7-is-going-end-of-support-on-30-june-2024/> Link: <https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Standards.html#C-Language> Cc: Dan Callahan <d.callahan@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-13Add a GitHub workflow status badge for our CI to the READMEAndrew Clayton1-0/+1
This shows the current state of our CI builds and points to the Unit workflows page. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-13Add a repostatus badge to the READMEAndrew Clayton1-0/+2
This is set to 'active' and is described here <https://www.repostatus.org/> This is now a requirement of F5/NGINX OSS projects. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-12Tests: NJS cacheable variables with access logAndrei Zeliankou1-0/+18
Reproduces issue https://github.com/nginx/unit/issues/1169.
2024-03-12NJS: loader should be registered using njs_vm_set_module_loader()Andrei Zeliankou6-25/+19
This change makes NJS module incompatible with NJS older than 0.8.3. Therefore, the configuration version check has been adjusted accordingly. This change was introduced in NJS 0.8.3 here: <https://hg.nginx.com/njs/rev/ad1a7ad3c715>
2024-03-11Fix the security-alert email link in the READMEAndrew Clayton1-2/+2
This fixes the security-alert email link to actually open up in an email client, rather than it trying to make the email link a part of the Unit repository URL. Fixes: fa42d858a ("Adding GitHub-styled README and CONTRIBUTING files in Markdown.") Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Avoiding arithmetic ops with NULL pointer in nxt_unit_mmap_getAndrei Zeliankou1-0/+6
Found by UndefinedBehaviorSanitizer. Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Initialize port_impl only when it is neededAndrei Zeliankou1-1/+1
Found by UndefinedBehaviorSanitizer. Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Avoiding arithmetic ops with NULL pointer in nxt_port_mmap_getAndrei Zeliankou1-0/+6
Can be reproduced by test/test_settings.py::test_settings_send_timeout with enabled UndefinedBehaviorSanitizer. Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Avoiding arithmetic ops with NULL pointer in nxt_http_arguments_parseAndrei Zeliankou1-0/+6
Can be reproduced by test/test_variables.py::test_variables_dynamic_arguments with enabled UndefinedBehaviorSanitizer: src/nxt_http_request.c:961:17: runtime error: applying zero offset to null pointer #0 0x1050d95a4 in nxt_http_arguments_parse nxt_http_request.c:961 #1 0x105102bf8 in nxt_http_var_arg nxt_http_variables.c:621 #2 0x104f95d74 in nxt_var_interpreter nxt_var.c:507 #3 0x104f98c98 in nxt_tstr_query nxt_tstr.c:265 #4 0x1050abfd8 in nxt_router_access_log_writer nxt_router_access_log.c:194 #5 0x1050d81f4 in nxt_http_request_close_handler nxt_http_request.c:838 #6 0x104fcdc48 in nxt_event_engine_start nxt_event_engine.c:542 #7 0x104fba838 in nxt_thread_trampoline nxt_thread.c:126 #8 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030) #9 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_request.c:961:17 Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Fixed undefined behaviour in left shift of int valueAndrei Zeliankou1-4/+4
Found by UndefinedBehaviorSanitizer: src/nxt_random.c:151:31: runtime error: left shift of 140 by 24 places cannot be represented in type 'int' #0 0x104f78968 in nxt_random nxt_random.c:151 #1 0x104f58a98 in nxt_shm_open nxt_port_memory.c:377 #2 0x10503e24c in nxt_controller_conf_send nxt_controller.c:617 #3 0x105041154 in nxt_controller_process_request nxt_controller.c:1109 #4 0x104fcdc48 in nxt_event_engine_start nxt_event_engine.c:542 #5 0x104f27254 in main nxt_main.c:35 #6 0x180fbd0dc (<unknown module>) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_random.c:151:31 Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11NJS: avoiding arithmetic ops with NULL pointer in r->argsAndrei Zeliankou1-2/+3
Can be reproduced by test/test_rewrite.py::test_rewrite_njs with enabled UndefinedBehaviorSanitizer: src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer #0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169 #1 0x102598ad0 in njs_value_property njs_value.c:1175 #2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398 #3 0x102559d74 in nxt_js_call nxt_js.c:445 #4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276 #5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56 #6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565 #7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998 #8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542 #9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126 #10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030) #11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52 Same fix was introduced in NJS: <http://hg.nginx.org/njs/rev/4fba78789fe4> Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Router: match when pattern and tested string are both zero lengthAndrei Zeliankou1-0/+4
Otherwise, undefined behaviour will be triggered. Can be reproduced by test/test_routing.py::test_routes_match_host_empty with enabled UndefinedBehaviorSanitizer: src/nxt_http_route.c:2141:17: runtime error: applying zero offset to null pointer #0 0x100562588 in nxt_http_route_test_rule nxt_http_route.c:2091 #1 0x100564ed8 in nxt_http_route_handler nxt_http_route.c:1574 #2 0x10055188c in nxt_http_request_action nxt_http_request.c:570 #3 0x10052b1a0 in nxt_h1p_request_body_read nxt_h1proto.c:998 #4 0x100449c38 in nxt_event_engine_start nxt_event_engine.c:542 #5 0x100436828 in nxt_thread_trampoline nxt_thread.c:126 #6 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030) #7 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_route.c:2141:17 Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Add dependabot.ymlDylan Arbour1-0/+6
We already use dependabot for security related patches, by default. This change adds a dependabot.yml configuration file that explicitly enables the service to manage versions of Actions in GitHub Actions. This ensures that Actions like `setup-go` are updated timely. This change does not affect how Dependabot manages versions for Go, Rust, etc. The file can be used to configure that for additional package managers and languages in the future, if desired.
2024-03-11Wasm-wc: Bump the mio crate from 0.8.10 to 0.8.11dependabot[bot]1-2/+2
Bumps mio <https://github.com/tokio-rs/mio> from 0.8.10 to 0.8.11. Fixes receiving IOCP events after deregistering a Windows named pipe. Not that that effects Unit... Link: <https://github.com/nginx/unit/security/dependabot/1> Link: Changelog <https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md> Link: Commits <https://github.com/tokio-rs/mio/compare/v0.8.10...v0.8.11> Signed-off-by: dependabot[bot] <support@github.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> [ Tweaked commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Add an EXTRA_CFLAGS make variableAndrew Clayton1-1/+4
This variable is _appended_ to the main CFLAGS variable and allows setting extra compiler options at make time. E.g $ make EXTRA_CFLAGS="..." ... Useful for quickly testing various extra warning flags. Suggested-by: Alejandro Colomar <alx@kernel.org> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Add a help target to the root MakefileAndrew Clayton1-0/+10
This adds a help target to the Makefile in the repository root that shows what variables are available to control the make/build behaviour. It currently looks like $ make help Variables to control make/build behaviour: make V=1 ... - Enables verbose output make D=1 ... - Enables debug builds (-O0) make E=0 ... - Disables -Werror Variables can be combined. Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Allow to disable -Werror at 'make' timeAndrew Clayton1-0/+8
Having -Werror enabled all the time when developing can be a nuisance, allow to disable it by passing E=0 to make, e.g $ make E=0 ... This will set -Wno-error overriding the previously set -Werror. Co-developed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Enable optional 'debuggable' buildsAndrew Clayton2-2/+11
One issue you have when trying to debug Unit under say GDB is that at the default optimisation level we use of -O (-O1) the compiler will often optimise things out which means they are not available for inspection in the debugger. This patch allows you to pass 'D=1' to make, e.g $ make D=1 ... Which will set -O0 overriding the previously set -O, basically disabling optimisations, we could use -Og, but the clang(1) man page says this is best and it seems to not cause any issues when debugging GCC generated code. Co-developed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the wasm language module compiler outputAndrew Clayton1-3/+5
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the wasm language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the Ruby language module compiler outputAndrew Clayton1-3/+5
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the Ruby language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the Python language module compiler outputAndrew Clayton1-3/+5
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the Python language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the PHP language module compiler outputAndrew Clayton1-2/+4
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the PHP language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the Perl language module compiler outputAndrew Clayton1-3/+5
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the Perl language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the Java language module compiler outputAndrew Clayton1-3/+5
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the Java language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Hook up make pretty printing to the Unit core and testsAndrew Clayton1-20/+40
This makes use of the infrastructure introduced in the previous commit to pretty print the make output when building the Unit core and the C test programs. When building Unit the output now looks like VER build/include/nxt_version.h (NXT_VERSION) VER build/include/nxt_version.h (NXT_VERNUM) CC build/src/nxt_lib.o CC build/src/nxt_gmtime.o ... CC build/src/nxt_cgroup.o AR build/lib/libnxt.a CC build/src/nxt_main.o LD build/sbin/unitd SED build/share/man/man8/unitd.8 I'm sure you'll agree that looks much nicer! You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Add initial infrastructure for pretty printing make outputAndrew Clayton1-0/+29
The idea is rather than printing out the full compiler/linker etc command for each recipe e.g cc -c -pipe -fPIC -fvisibility=hidden -O0 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wno-strict-aliasing -Wmissing-prototypes -g -I src -I build/include \ \ \ -o build/src/nxt_cgroup.o \ -MMD -MF build/src/nxt_cgroup.dep -MT build/src/nxt_cgroup.o \ src/nxt_cgroup.c Print a clearer abbreviated message e.g the above becomes CC build/src/nxt_cgroup.o This vastly reduces the noise when compiling and most of the time you don't need to see the full command being executed. This also means that warnings etc show up much more clearly. You can still get the old verbose output by passing V=1 to make e.g $ make V=1 ... NOTE: With recent versions of make(1) you can get this same, verbose, behaviour by using the --debug=print option. This introduces the following message types CC Compiling a source file to an object file. AR Producing a static library, .a archive file. LD Producing a dynamic library, .so DSO, or executable. VER Writing version information. SED Running sed(1). All in all this improves the developer experience. Subsequent commits will make use of this in the core and modules. NOTE: This requires GNU make for which we check. On OpenIndiana/illumos we have to use gmake(1) (GNU make) anyway as the illumos make doesn't work with our Makefile as it is. Also macOS seems to generally install GNU make. We could make it work (probably) on other variants of make, but the complexity starts increasing exponentially. In fact we still print the abbreviated messages in the verbose output so you can still do $ make | grep ^" [A-Z]" on other makes to effectively get the same output. Co-developed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Compile with -fno-strict-overflowAndrew Clayton1-0/+4
This causes signed integer & pointer overflow to have a defined behaviour of wrapping according to two's compliment. I.e INT_MAX will wrap to INT_MIN and vice versa. This is mainly to cover existing cases, not an invitation to add more. Cc: Dan Callahan <d.callahan@f5.com> Suggested-by: Alejandro Colomar <alx@kernel.org> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Disable strict-aliasing in clang by defaultAndrew Clayton1-2/+4
Aliasing is essentially when you access the same memory via different types. If the compiler knows this doesn't happen it can make some optimisations. There is however code in Unit, for example in the wasm language module and the websocket code that may fall foul of strict-aliasing rules. (For the wasm module I explicitly disable it there) In auto/cc/test for GCC we have NXT_CFLAGS="$NXT_CFLAGS -O" ... # -O2 enables -fstrict-aliasing and -fstrict-overflow. #NXT_CFLAGS="$NXT_CFLAGS -O2" #NXT_CFLAGS="$NXT_CFLAGS -Wno-strict-aliasing" So with GCC by default we effectively compile with -fno-strict-aliasing. For clang we have this NXT_CFLAGS="$NXT_CFLAGS -O" ... #NXT_CFLAGS="$NXT_CFLAGS -O2" ... NXT_CFLAGS="$NXT_CFLAGS -fstrict-aliasing" (In _clang_, -fstrict-aliasing is always enabled by default) So in clang we always build with -fstrict-aliasing. I don't think this is the best idea, building with something as fundamental as this disabled in one compiler and enabled in another. This patch adjusts the Clang side of things to match that of GCC. I.e compile with -fno-strict-aliasing. It also explicitly sets -fno-strict-aliasing for GCC, which is what we were getting anyway but lets be explicit about it. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Expand the comment about -Wstrict-overflow on GCCAndrew Clayton1-1/+3
Expand on the comment on why we don't enable -Wstrict-overflow=5 on GCC. Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96658> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove -W from compiler flagsAndrew Clayton1-2/+2
This is what -Wextra used to be called, but any version of GCC or Clang in at least the last decade has -Wextra. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Sun's Sun Studio/SunPro C compilerAndrew Clayton4-140/+0
We really only support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for IBM's XL C compilerAndrew Clayton3-176/+1
We really only support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Intel's icc compilerAndrew Clayton1-11/+0
We only really support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Microsoft's Visual C++ compilerAndrew Clayton2-13/+0
We don't run on Windows and only really support compiling Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Co-developed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-08Var: Fix cacheable issue for njs variable accessZhidao HONG1-1/+1
The variables accessed with JS template literal should not be cacheable. Since it is parsed by njs engine, Unit can't create indexes on these variables for caching purpose. For example: { "format": "`{bodyLength:\"${vars.body_bytes_sent}\",status:\"${vars.status}\"}\n`" } The variables like the above are not cacheable. Closes: https://github.com/nginx/unit/issues/1169
2024-03-07.mailmap: Map Dylan's 2nd GitHub addressDylan Arbour1-0/+1
I changed a setting and now GitHub will recognize both the legacy numberless version, and the newer version with UserID. The with-UserID version will be used by the any changes stemming from the GitHub GUI. Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Dylan Arbour <d.arbour@f5.com>
2024-03-07Add GitHub workflow for wasm-wasi-componentAndrew Clayton1-5/+35
This adds a GitHub CI workflow for the new wasm-wasi-component language module. Some things of note. 1) We need to special case 'wasm-wasi-component' in the 'Output build metadata' section as we are splitting the module names on '-' to split them into name and version. 2) Apart from needing to tell bindgen about the njs include paths, we also need to explicitly specify which version of clang to use to work around an issue with multiple versions of clang installed. Link: <https://gitlab.freedesktop.org/mesa/mesa/-/issues/7268> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-07Test with root access in GitHub workflowsDylan Arbour1-31/+13
To enable tests that require privileged root access, this commit tests with `sudo`. The Java and Python jobs have additional permissions issues, so they are also configured and made with `sudo`. A small permissions fix is required before running tests to allow non-root users to execute within the `/home/runner` directory. This change also removes the custom directories that were required without root access. Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Dylan Arbour <d.arbour@f5.com>
2024-03-05Avoid potential NULL pointer dereference in nxt_router_temp_conf()Andrew Clayton1-7/+9
In nxt_router_temp_conf() we have rtcf = nxt_mp_zget(mp, sizeof(nxt_router_conf_t)); if (nxt_slow_path(rtcf == NULL)) { goto fail; } If rtcf is NULL then we do fail: if (rtcf->tstr_state != NULL) { nxt_tstr_state_release(rtcf->tstr_state); } In which case we will dereference the NULL pointer rtcf. This patch re-works the goto labels to make them more specific to their intended purpose and ensures we are freeing things which have been allocated. This was found by the clang static analyser. Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-05Var: Remove a dead assignment in nxt_var_interpreter()Andrew Clayton1-1/+1
p is not used again before returning from the function. Found by the clang static analyser. Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-05Remove unused nxt_vector_t APIAndrew Clayton4-223/+0
This is unused, yet a community member just spent time finding and fixing a bug in it only to be told it's unused. Just get rid of the thing. Link: <https://github.com/nginx/unit/pull/963> Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-29Configuration: Fix check in nxt_conf_json_parse_value()Andrew Clayton1-1/+1
If we compile Unit with -Wstrict-overflow=5 (as we do with clang) then we get the following warning cc -c -pipe -fPIC -fvisibility=hidden -O0 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wstrict-overflow=5 -Wmissing-prototypes -g -I src -I build/include \ \ \ -o build/src/nxt_conf.o \ -MMD -MF build/src/nxt_conf.dep -MT build/src/nxt_conf.o \ src/nxt_conf.c src/nxt_conf.c: In function ‘nxt_conf_json_parse_value’: src/nxt_conf.c:1444:5: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C2 -+ C1 [-Wstrict-overflow] 1444 | if (nxt_fast_path((ch - '0') <= 9)) { | Does this actually cause an issue?... well, yes. Using this minimal test config to show the problem { "listeners": { "[::1]:8080": { "pass": --100 } } } With the above if () statement that triggers the warning, my assumption here is that we only want a digit now. '0' - '9'. ch is a u_char, however if ch is any character with an ASCII code < 48 ('0') e.g if ch is '-' (45) then we get 45 - 48 = -3, through arithmetic conversion, which makes the if () statement true (when it shouldn't) then at some point we get the following error returned from the controller { "error": "Memory allocation failed." } Instead of the expected { "error": "Invalid JSON.", "detail": "A valid JSON value is expected here. It must be either a literal (null, true, or false), a number, a string (in double quotes \"\"), an array (with brackets []), or an object (with braces {}).", "location": { "offset": 234, "line": 15, "column": 27 } } Casting the result of (ch - '0') to u_char resolves this issue, this makes the above calculation come out as 253 (relying on unsigned integer wraparound) which was probably the intended way for it to work. Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-27Wasm-wc: use more common uname switch to get operating system nameKonstantin Pavlov1-1/+1
-o is not available on macOS 12.7 at least, and it's what homebrew seems to support still. Also, the proposed switch seems to be used already in the codebase.