-------- In message <[email protected]>, Nils Goroll writes:
>- 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. >- 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. >- 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. Part of the problem is that C is a shitty language to implement iterators in (and we have like 4-5 different ones already, don't we ?) >- 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
