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).
On Friday, September 9, 2016 12:18 PM, James Peach <jpe...@apache.org>
wrote:
> On Sep 9, 2016, at 10:15 AM, Susan Hinrichs
> <shinr...@network-geographics.com> wrote:
>
>
>
> On 9/9/2016 12:01 PM, James Peach wrote:
>>> On Sep 9, 2016, at 9:39 AM, Susan Hinrichs
>>> <shinr...@network-geographics.com> 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?
