Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Put some serious red tape on VCL_STRANDS
I started suspecting that we need this clarification during the review of #3123 [1] and was able to verify it with a simple test case. First I needed a function I put in vmod_debug: $Function STRANDS hoard_strands(PRIV_TASK, STRANDS s) Return the first value of s for the rest of the task. The implementation is very straightforward: struct hoarder { VCL_STRANDS s; }; VCL_STRANDS xyzzy_hoard_strands(VRT_CTX, struct vmod_priv *priv, VCL_STRANDS s) { struct hoarder *h; CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); AN(priv); if (priv->priv == NULL) { h = malloc(sizeof *h); AN(h); h->s = s; priv->priv = h; priv->free = free; } return (priv->priv); } And then the following test case results in a panic on my system, but I suspect this is generally undefined behavior and other nasty results may occur under different circumstances: varnishtest "Beware of STRANDS" varnish v1 -vcl { import debug; backend be none; sub vcl_recv { debug.hoard_strands("recv: " + req.url); } sub vcl_miss { debug.hoard_strands("miss: " + req.url); return (synth(200)); } sub vcl_synth { set resp.body = debug.hoard_strands("synth: " + req.url); return (deliver); } } -start client c1 { txreq rxresp expect resp.body ~ recv } -run This also begs the following question: can it ever be safe to let a VMOD function return a STRANDS? Maybe it should be banned from return types. [1] #3123 (comment)
- Loading branch information