Jenkins build is back to normal : 3.HEAD-amd64-centos-6 #142

[noc]

See 

Re: [RFC] Tokenizer API

[Francesco Chemolli]

[...]

> 
> Given the number of cases where folks wrote the _wrong_ length already,
> I suggest the following plan:
> 
> 1. Do not support the len argument. Use the add-single-character
> interface to add \0 when/if needed.
> 
> 2. If we find ourselves adding \0 (and nothing else) too much, revisit
> this issue.

Ok, I'll do so.

Re: [RFC] Tokenizer API

[Alex Rousskov]

On 12/11/2013 11:15 AM, Kinkie wrote:
>>>   CharacterSet(const char * const c, size_t len)
>>
>> You do not want the len argument. These character sets will be nearly
>> always initialized once, from constant hard-coded c-strings.
>> For esoteric cases, I would add an add(const char c) method to add a
>> single character to the set (and use the merge operation to produce more
>> elaborate sets as needed, see below for a sketch).
> 
> Yes, but without it it's not possible to specify \0 as a valid
> character in the set.

Yes, but \0 can be specified using the add-single-character interface
which is useful for other reasons (see my earlier email with a sketch
adding a single \r character). I suspect \0 is going to be rarely used.


> Possible solution: make len optional. If 0, default to strlen().
> That would allow to cover one possible esoteric case without impacting
> the common case. What do you think?

Given the number of cases where folks wrote the _wrong_ length already,
I suggest the following plan:

1. Do not support the len argument. Use the add-single-character
interface to add \0 when/if needed.

2. If we find ourselves adding \0 (and nothing else) too much, revisit
this issue.


HTH,

Alex.

Re: [RFC] Tokenizer API

[Kinkie]

>>   CharacterSet(const char * const c, size_t len)
>
> You do not want the len argument. These character sets will be nearly
> always initialized once, from constant hard-coded c-strings.
> For esoteric cases, I would add an add(const char c) method to add a
> single character to the set (and use the merge operation to produce more
> elaborate sets as needed, see below for a sketch).

Yes, but without it it's not possible to specify \0 as a valid
character in the set.
Possible solution: make len optional. If 0, default to strlen().
That would allow to cover one possible esoteric case without impacting
the common case. What do you think?

Kinkie

Re: [PATCH] sslcrtvalidator_children concurrency option default value

[Tsantilas Christos]

On 12/11/2013 12:09 AM, Amos Jeffries wrote:
> On 2013-12-11 10:46, Tsantilas Christos wrote:
>> Hi all,
>>
>> currently we have the following situation for sslcrtvalidator_children
>> configuration option, which is may confusing people:
>>  1) The testing sslcrtvalidator helper supports concurrency
>>  2) The default concurrency if the sslcrtvalidator_children is not set,
>> is concurrency=0
>>  3) The default sslcrtvalidator_children line includes concurrency=1
>>  4) The documentation says:
>>  "Defaults to 0 which indicates the certficate validator
>>   is a old-style single threaded redirector."
>>
>> This is make a confusion.
>>
>> I am attaching a simple patch which set the concurrency option for
>> sslcrtvalidator_children by default to 1. I believe that this is the
>> best because the testing helper we provide supports concurrency by
>> default.
>>
>> Other options is
>>a) set sslcrtvalidator_children default line to use concurrency=0
>>b) Make a better documentation of the current behaviour to cf.data.pre
>>
>>
>> Opinions?
> 
> +1. Looks good. But can you change the new documentation line to avoid
> calling it a redirector and single-threaded?  "A value of 0 indicates
> the certficate validator does not support concurrency." should be fine.

Thank you. I will apply with this change.


> 
> Amos
>