>> - 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 _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
