1.
On Friday, September 9, 2016 1:19 PM, James Peach <[email protected]> wrote:
> On Sep 9, 2016, at 10:55 AM, Alan Carroll
> <[email protected]> wrote:
>
> No. I'm not completely sure what I meant when I wrote that (maybe it was a
> typo). My view on review was that it should be an in/out parameter where the
> tag (possibly just a prefix) is passed in and the actual tag found is passed
> back. Susan has convinced me it would be better to make split that in to two
> parameters, the second being optional (can be NULL). So the last arg becomes
> "char const* tag, char const** result" where
> tag - the tag to search for, using an anchored prefix search.result -
> optional return value for the tag found (if NULL the found tag is not
> returned).
How many results can you get?
>
>
> On Friday, September 9, 2016 12:18 PM, James Peach <[email protected]>
>wrote:
>
>
>
>> On Sep 9, 2016, at 10:15 AM, Susan Hinrichs
>> <[email protected]> wrote:
>>
>>
>>
>> On 9/9/2016 12:01 PM, James Peach wrote:
>>>> On Sep 9, 2016, at 9:39 AM, Susan Hinrichs
>>>> <[email protected]> wrote:
>>>>
>>>> I'd like to propose a slight tweak for
>>>> TSHttpTxnClientProtocolStackContains and
>>>> TSHttpSsnClientProtocolStackContains
>>>>
>>>> Replace the tag argument with two explicit input and output arguments, e.g.
>>>>
>>>> int TSHttpTxnClientProtocolStackContains(TSHttpTxn txnp, char const
>>>> *contains_tag, char const **specific_tag_ptr)
>>> The TSHttpTxnClientProtocolStackContains didn't mention anything about any
>>> output?
>>
>> I was assuming that something was being returned via the tag argument since
>> we are passing in a pointer to a pointer.
>
> It takes a nul-terminated array of tags right?
