When VJSN is both in libvarnish and libvarnishapi, as in varnishtest,
you would think one of them took precedence, but not so on OSX.

In the shlib (libvarnishapi) text (code) symbols come from the version
in the main binary (varnishtest) which got it from libvarnish, whereas
the data symbols come from the version in libvarnishapi, so we now
hide the data symbols behind code.

Ref 611baec6

... but we can not make any assumption as to why

Fixes #3664

add a vmod function for strftime() formatting in UTC.

As a follow-up issue from #3719, it was noticed that dynamic calls to
built-in SUBs did not work.

This issue was caused by more (struct symbol) members missing
initialization in VCC_New().

In turn, it became apparent that the evaluation context check in
vcc_expr5() as tested in v00020.vtc only worked by accident, and only
for built-in subs because (struct symbol).eval was NULL for built-in
subs.

We fix SUB type expression evaluation with a type specific evaluation
function which allows expression evaluation from explicit SUB contexts
only.

Fixes #3720

vcc_act_call() implements use-before-define semantics. To do so, it
needs to instantiate SUB symbols if they do not exist.

However, it wrongly called VCC_GlobalSymbol() also for existing
symbols, overwriting symbol properties.

In the case of the built-in subs, the symbol's lname (historically)
still is the unescaped literal name, while user defined subs have
their name escaped via VCC_GlobalSymbol() -> VCC_PrintCName().

This made the wrong call to VCC_GlobalSymbol() apparent when a
built-in sub was called with an explicit "call" action.

Besides fixing the VCC_GlobalSymbol() call, we also need to set the
lname and rname attributes for built-in SUB symbols initialized in
VCC_New().

Alternatively, we could also have used VCC_GlobalSymbol() there, but
that would have affected other places where we (still) rely on the
known name scheme of built-in subs, e.h. EmitStruct(). While the name
unifaction was nice in general, I found the necessary changes (look up
SUB symbols) not worth the benefit.

Fixes #3719

Already archived since there are no more occurrences in trunk, but it
could be useful on other branches or third-party libvarnish consumers.

The coccinelle patch also takes care of the recent manual refactoring.

Refs 4ae73a5b
Refs cf00dd2e

is still deranged. (See: CERT secure coding POS04-C)

Also prepare a global condattr_monotime, which will soon be used.

Increment client_req_400 in more cases.

Spotted by: Dridi

Info 776 (Possible truncation of addition): I found no better way than
using an additional size_t argument. This triggered a subsequent
warning about an out-of-bounds access, which could be silenced with
additional assertions on nac to be large anough such that av[ac] was
not out of bounds.

Warning 429: Custodial pointer 'av' (line 60) has not been freed or
returned:

In other cases, the argument vector comes from VAV_Parse() which
flexelint apparently can't follow along, yet memory for a VAV is also
allocated and never freed (see also bottom of STV_Config()).

In this case I found no better way than to silence flexelint.

Declare anonymous vsmw_cluster and vsc_seg structs in VSC header
files. This is to silence errors when the header file is used in other
contexts that don't know about these structs.

This is to resolve the chicken and egg problem of the VSC headers being
generated only once bin/varnishd is built, while they are used in several
VMODs and libraries.

This moves the generation of the VSC .c and .h header files to a directory
in lib that can be built earlier than its dependencies.

Also Don't AC_SUBST the vsc files. The complete list of vsc files is known
and listed in the .am file when automake is run, so there is no need to
have configure.ac help with making lists.