vpax

What's confusing is that this is using the deprecated semantics, which IIRC I pretty much left unmodified. That said, I'll toss this on my to-do pile.

> Adding this here for thoughts: @ckreibich mentioned that an `analyzer_not_implemented` or `analyzer_todo` event came up in discussions with @vpax (?) to raise information from an analyzers to script land...

Yes I've been seeing that too.

Just did a fresh build (well, Master as of a few days ago) and also got these messages under MacOS Big Sur: > In file included from ../auxil/broker/caf-incubator/libcaf_net/caf/net/length_prefix_framing.hpp:17: ../auxil/broker/caf-incubator/libcaf_net/caf/net/message_flow_bridge.hpp:46:7: warning:...

FYI, the high-level work items for this are: 1. Understand full functionality currently provided by `bifcl` to determine ease of supporting via C++ compilation 2. Determine whether to fully replace...

I see the basic problem. What has me confused is how the code could have ever worked! More in a bit when I get time to poke a bit further.

Okay, here's the problem. The type-checking for function calls gives a free pass to any function that has a single argument of type `any`: https://github.com/zeek/zeek/blob/e93fcd3c648ea2cc5ece592c4ec4273f58308f8c/src/Expr.cc#L5422 This is to support variadic...

To-dos: 1. Integrate https://github.com/zeek/zeek/pull/1462 PR 2. Develop CMake support for work-flows for different usage modalities (generating main code; adding new code to an existing base; running the test suite using...

> This is probably going to miss 4.1 since we're in RC1 already @timwoj not sure what you mean here by the scope of "This". The non-optional parts of that...

Here's the original to-do list, annotated: - [X] Integrate Prep work for Script Compilation: Expanded Function Profiling #1462 PR - [~] Develop CMake support for work-flows for different usage modalities...