* origin/topic/vern/CPP-Oct23-maint:
minor updates to -O gen-C++ maintenance notes and scripts
ZAM fix for inlining bug when a local is assigned to a function parameter
ZAM fixes for record creation and table indexing potentially having side-effects
removed order-of-evaluation ambiguity from new BTest
introduce internal "mask" expression node to avoid mixed-type overloading of "/"
fix bug in failing to concretize empty vectors
ZAM BTest update to match recent change to one of the tests
fixed ZAM reduction bug in += / -= operators
For CI and more general BTest execution we already enabled ccache
previously, but developers using a Spicy build out of the build
directory still needed to manually set up caching.
With this patch we enable it for such cases as well via
`zeek-path-dev.*sh`.
Slightly adapted. I wasn't sure how much guarantee we have around the
change propagation when calling terminate() right after the delete.
Flipped it around a bit, having the worker outlive the manger instead.
Since enabling Spicy, 500M (default) of ccache max-size size is not
sufficient for efficient cache usage of a Zeek build anymore, so we
end up thrashing the configured ccache. Build times have increased
from 5-10 minutes to 1+ hour after enabling Spicy in the docs build.
When inspecting Spicy values for marshalling to Zeek we should receive
field identifiers as owned `std::string` so it should be safe to
directly compare them against `const char[]`. It seems that e.g.,
gcc-9.4.0's analysis sees things differently and warns of a comparision
of `const char*` (which as written would compare pointer values; the
correct API for this would be `::strlen`).
This patch addresses that warning by visiting with type which supports
`==` comparison, in particular, take a `std::string_view` so we could
even visit `const char*` identifiers.
When there are errors reported during yyparse(), Zeek still continued
running initialization functions like init_general_global_var(), init_net_var()
and run_bif_initializers(). These usually call abort() in unexpected
situations causing misleading and confusing errors. This patch prevents
this by exiting earlier.
Closes#3316
These tasks are meant to run nightly on the master branch. Currently,
the external dns, http and dhcp Spicy analyzers are installed via zkg
post building. The build artifact is uploaded to Cirrus and the benchmarker
API triggered.
For the spicy_head task, the auxil/spicy submodule is pulled to the latest
commit. This also provides a bit of a nightly integration test.
* origin/topic/bbannier/btest-issue-98:
Use unique port for test `scripts.base.utils.active-http`
Do not automatically load Spicy modules in dot paths.
Exclude dot directories when searching ZEEK_PLUGIN_PATH
Dot directories rarely contain anything we would want to load as a
dynamic plugin. Even worse, they likely contain files with externally
controlled lifetimes which might be removed while we are using them
(see e.g., zeek/btest#98).
With this patch we do not search _discovered_ dot directories anymore.
We continue to load from a user-specified `ZEEK_PLUGIN_PATH`, even if
its name starts with a dot.
Since this patch changes previous behavior it is a **BREAKING CHANGE**.
On Slack, a user reported "fortify source" aborts within ares_fds() due
to the FDs used by c-ares exceeding 1024 and thereby larger than the
maximum fd value that a fd_set can hold.
Switch to ares_get_socks() and poll() to avoid this.
Closes#3309.
Similar motivation as for RecordVal, save an extra malloc/free
and pointer indirection.
This breaks the `auto& RawVec()` API which previously returned
a reference to the std::vector*. It now returns a reference
to the vector instead. It's commented as intended for internal
and compiled code, so even though it's public API,
The previous `std::vector<std::optional<ZVal>>*&` return type was also very
likely not intended (all consumers just dereference it anyhow). I'm certain
this API was never meant to modify the actual pointer value.
I've switched to explicit typing, too.
A user reported that they ran into a situation where a parse error
caused an assertion failure in `reject_protocol`. printf debugging points
to the `CookieSetter`s in the `try`/`catch` blocks during processing
already clearing the cookie RAII-style; since their `catch` blocks
already send an analyzer violation no further sending of one from
`reject_protocol` is required.
This patch replaces the assert in `reject_protocol` with a runtime check
and an early return if the cookie is already cleared.
