On 13 Apr 2008, at 08:03, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>,
> Paul Nasrat w
> rites:
>>
>> On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote:
>>
>>> Your patch breaks the convention that compiled code only calls VRT_*
>>> functions, you need to keep a VRT_re_test() wrapp
In message <[EMAIL PROTECTED]>, Paul Nasrat w
rites:
>
>On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote:
>
>> Your patch breaks the convention that compiled code only calls VRT_*
>> functions, you need to keep a VRT_re_test() wrapper around for that
>> reason.
>
>I'm not sure that's breaking that
On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote:
> Your patch breaks the convention that compiled code only calls VRT_*
> functions, you need to keep a VRT_re_test() wrapper around for that
> reason.
I'm not sure that's breaking that convention - the call chain is in
vcc_regexp and it's a te
I was wanting to start looking at the vcl parser, and noticed that you
can't link against just libvcl to call VCC_CompileFile due to
VRT_re_test being called in vcc_string.c.
Although varnishd supports -C to parse only
The attached patch against trunk moves and renames the re_test method
i
In message <[EMAIL PROTECTED]>, Paul Nasrat w
rites:
>> The attached patch against trunk moves and renames the re_test
>> method into vcc_string.c so libvcl could be used outside of varnishd.
>-int
>-VRT_re_test(struct vsb *sb, const char *re, int sub)
>-{
Your patch breaks the convention that
On 12 Apr 2008, at 16:31, Paul Nasrat wrote:
I was wanting to start looking at the vcl parser, and noticed that
you can't link against just libvcl to call VCC_CompileFile due to
VRT_re_test being called in vcc_string.c.
Although varnishd supports -C to parse only
The attached patch against