> On Sep 9, 2016, at 10:55 AM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> 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 <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?
