Even when it was introduced, it was inaccurate.

e39e5e0d continued

Minor uncluttering, no code change other than use of that local
variable.

The fetch_objcore must not change for the duration of a fetch.

it is part of the filter side of things, while the remaining
declarations in cache_varnishd concern the interface between filters and
the rest of the code.

This also parallels the location of VDP_Push()

Test inspired by Carlos Abalde

		if (e - p < l1 + l2)
../../lib/libvarnishapi/vsl_arg.c  133  Info 776: Possible truncation of
    addition

depending on our platform and the timing of events, we might see another
overflow.

Seen with vtest

---- v1   Not true: ws_session_overflow (3) == 2 (2)

we want to make sure that we do not hit timeout_idle as long as we stay
below it, but the margin of just 100ms has triggered a false negative.
Double the margin to 200ms...

see with vtest (c4u lines extracted)

**** c4u  Loop #3
**   c4u  === delay 0.3
***  c4u  delaying 0.3 second(s)
**** dT   2.025
**   c4u  === sendhex 0d0a
**** c4u  sendhex|  0d 0a
---- c4u  Write failed: Socket is not connected

sorry, I overlooked the sixth spot from a total of five different source
files.

Parameters are passed to vcc via specific setter functions, presumably
to avoid binary compability issues between the main program (here:
vanishd) and a library (here: libvcc).

This commit does not change that interface in any way, but generates
both sides from a common table include to avoid having to edit five
spots in four different source files and write trivial setter functions
for a simple mgt_vcc parameter change.

* there is no NULL filter
* the filter name cannot be NULL or empty

See previous commit: Analogous to resp.do_esi, any access to the
beresp.do_* flags which influence beresp.filters is now a VCL error.

Ref #3002

After fixing resp.filters, resp.do_esi loses its meaning.

Note:

Setting resp.filters also fixes whether or not the gunzip and range VDPs
are being pushed.

These do not depend on switches, but on request headers. So we need to
consider the case that a VCL author

	- fixes resp.filters
	- and then adds or removes relevant headers

* req.http.Accept-Encoding for the gunzip vdp

  if removed: gunzip stays in the VDP list, which is always ok

  if added: that is probably wrong anyway and the VCL author can
  be held responsible for their actions as per the warning in the
  resp.filters documentation.

* req.http.Range for the range vdp

  if removed: the range vdp vetoes itself in the _init callback

  if added: no range handling will be present, which is always ok
  (and see above for VCL author responsibilities)

Fixes #3002

The synthetic response has nothing to do with the filters set for
the original body.

See next commit for implicit test

We do not know if we are going to send a body when we construct the
filter list. It is up to the vdps to handle a null response

Ref #3002

So far, we relied upon esi not being added to resp_filters for no esi
object, but as the filters can be set freely from VCL, the esi vdp
itself should veto being pushed if it has not business to do with the
object at hand.

Ref #3002

sorry, I got the first attempt wrong

reported by flexelint

reported by flexelint

spotted by flexelint

Ref a67a9d56

Spotted by flexelint

Ref: 6c8f25e7

I did not understand when I committed
119b4174 that the local variable was
required for flexelint to unterstand that this is not an out-of-bounds
access.

This quote of phk from the top level rant sais it all:

 * Do I need to tell you that static code analysis tools have a
 * really hard time coping with this, and that they give a lot of
 * false negatives which confuse people ?

So true. Sorry for going a smaller but almost full circle here, I
started with good intentions and now all that's left is the desire to
leave the code at least a little cleaner as I found it.

I would have preferred avoiding the duplication of the suckaddr member
types, but flexelint spits "Warning 550: Symbol 'sua' (line 229) not
accessed"

vtest has seen a case where other workspace debug messages interfered.

FTR, it would be nice if we could backref a prior expect in order to
expect the same workspace address

Across the platforms we support, the overhead of stevedore allocations
varies slightly due to different sizes of our structs.

const char *const bindings_help[] = {
varnishstat_curses_help.c  9  Note 9075: external symbol 'bindings_help'
    defined without a prior declaration
                            _
const int bindings_help_len = 65;
varnishstat_curses_help.c  78  Note 9075: external symbol
'bindings_help_len'
    defined without a prior declaration

Could be that there is the bereq # printed right next to the client |
as in this vtest result:

**   top  === process p1 -expect-text 22 0 { | }
**** dT   3.593
**** v1   vsl|          0 CLI             - Rd ping
**** v1   vsl|          0 CLI             - Wr 200 19 PONG 1585796425 1.0
**** dT   3.806
**** p1   stdout|\x1b[1;10H2\x1b[22;24H|#

when the second request did not happen within the default
backend_remote_error_holddown == 0.25s, we would see two ECONNREFUSED
instead of one and a holddown.

Seen in vtest:

**   top  === varnish v1 -expect VBE.vcl1.foo.fail_econnrefused > 0
**** dT   6.132
**   v1   as expected: VBE.vcl1.foo.fail_econnrefused (2) > 0
**   top  === varnish v1 -expect VBE.vcl1.foo.helddown > 0