BLOBs as iterators / WS_Append

[Nils Goroll]

>> - As briefly discussed on the VDD, I think that we should change VMOD BLOBs to
>>  be struct objcore *
> 
> No, we certainly should not tie them to objcore.  If we make them iterators,
> it will be a general stand alone type of iterator, where implementations can
> iterate over anything they want, including objcores.

Sounds better, yes.

>> - candiates for stringifications should get an additional null byte after the
>>  blob end (if they don't have it, stringification would replace the last blob
>>  chunk)
> 
> This would be an implementation detail in the iterator-implementation,
> ie: the BLOB-iterator for objcores would have a private secret
> agreement with the fetch code to always ensure the NUL is there so it
> can rely on it.

OK.

>> - blob2string could just create an obj on the WS
> 
> So this is where it gets interesting.
> 
> The current STRING_LIST is a sort of cheasy iterator which works really
> well when you interpret VCL string concatenation into C source.  It is
> relevant question if the same iterator mechanism should be used for
> STRING(_LIST?) and the current vararg based STRING_LIST would merely
> become a convenient VCC implementation of such an iterator.
> 
> I need to ponder the pros and cons of this entire thing.

Also we could keep the varargish interface and add a TXT_LIST. It's cheesy, but
it's cheap - saving the iterator overhead for simple cases.

>> - WS_Copy is useful, but for stringification f-pointer alignment is in the way
>>  -> I think we should have WS function variants for unaligned (char *) ptrs.
> 
> Performance wise it is a very good idea to align strings, many optimized
> versions of string functions rely/expect them to be.

I am well aware of the advantages of proper alignment. Remember
https://www.varnish-cache.org/trac/attachment/ticket/665/varnish_Malloc_Calloc.patch
?

Yes, ws allocations should be aligned by default. But we should have a way to
just append to the ws. I'll propose a patch