After the removal of VSB_new() and VSB_delete().

Refs 5884e2f2

This will hopefully silence our continuous integration complaining way
too often about server leaking what http_process_cleanup() should take
care of.

The nested while loop made more sense when the surroundings were more
complicated.

Better diff with the --ignore-all-space option.

All call sites pass a non-null char pointer.

There might be linker flags that cat would fail to find.

Otherwise we always try to rebuild vrt_test when running make.

Spotted by Simon Vikström.

Closes #3671

And use the 64bit default as a dynamic default to have it show up in the
varnishd manual. Since we explicitly document the 32bit default in the
same manual it shouldn't be controversial.

The reason to increase them is the PCRE2 jit compiler that produces
stack-hungry code.

Refs #3671

It is the minimum value that matches the dynamic description, the
default value gets adjusted if the one we use is below on a given
system.

either or both of which are allowed to be NULL.

(Part of STRING_LIST eradication)

When we check sym->wildcard for quoted headers.

Because we funnel HTTP header names through the symbol table they have
to be valid VCL identifiers. It means that we can't support all valid
header names, which are tokens in the HTTP grammar. To finally close this
loophole without the help of a VMOD we allow header names to be quoted:

    req.http.regular-header
    req.http."quoted.header"

However we don't want to allow any component of a symbol to be quoted:

    req."http".we-dont-want-this

So we teach the symbol table that wildcard symbols may be quoted. There
used to be several use cases for wildcards but it is now limited to HTTP
headers.

Refs #3246
Refs #3379

The miniobj resides in the workspace it's rolling back. To preserve its
zeroing we need to roll back afterwards.

It's harmless with a regular workspace, but technically we are leaving
outstanding allocations in the workspace.

It's harmless with a regular workspace, but technically we are leaving
outstanding allocations in the workspace.

After a cleanup we may still use the request's workspace, so the final
rollback should instead happen at release time before we give the memory
back to the pool.

PAN_dump_struct2() is now renamed to PAN__DumpStruct() following the
guidelines from apispaces.rst in addition to growing a track argument.
This should allow dumping structures that we know ought to be dumped
only once, in case they would be numerous.

There seems to be no good reason to expose it to VMODs yet since they
have no integration point with the panic output, so those definitions
can be confined in cache_varnishd.h for now.

Better diff with the --ignore-all-space option.

In the most common case of a VCL transaction panicking this should only
result in an extra "Already dumped, see above" message, but it may give
more insights for other kinds of tasks.

Getting rid of the very last direct access inside struct ws from
vmod_vtc.

Releasing a reservation or rolling back too early is harmless as long as
nothing is allocated on the workspace that could overwrite its contents.

Once you swap the workspace in its current form with a different kind of
allocator it can turn into effective use-after-free, if rolled back or
released state doesn't linger.

Instead of guaranteeing the pointer alignment of ws->r at the expense of
sometimes reserving more than requested, we can instead drop the pointer
alignment requirement since that does not refer to the beginning of the
allocation.

Instead, it is in WS_Release() that we guarantee that the ws->f remains
aligned for the next allocation. And WS_Release() already did that so we
might as well avoid the potential overcommit from WS_ReserveSize().

This is going to be helpful for a workspace emulator, to make sure that
the alignment overhead wouldn't allow off-by-little overflows to sneak
past the address sanitizer. This very change was initially made for a
workspace sanitizer.

It is also a good occasion to make the relevant checks around the ws->r
pointer in WS_Assert().

This change is visible in r03131.vtc that now exhibits this behavior.

Refs #3320

Not even failing to allocate, but outright panicking.