I'll wait a couple more days for input, then I'll change it to return char
* and take an int * parameter to output the length.  If we're switching to
C++, we can update this based on whatever consensus we reach for the
switchover strategy.

On Wed, Jan 4, 2023 at 7:03 PM Masakazu Kitajo <mas...@apache.org> wrote:

> > They could make the returned structure a nesting structure in
> their structure.
>
> What if the structure is defined by a library and a plugin author can't
> modify it? What I'm trying to say is that I don't see the benefit of
> limiting how a user receives the pointer and the length where nothing
> receives TSVarLenData. Do we require two copy ops for the "unusual" case
> just to avoid having two variables by providing TSVarLenData? Is it that
> convenient?
>
> I don't have a strong opinion about moving to C++ at the moment, but if we
> go that way and start using string_view, TSVarLenData wouldn't be used for
> new APIs. And we'd add a string_view version of an old API that uses
> TSVarLenData so that users can easily pass the returned value to other
> functions. Then we'd deprecate the old API and remove it in the future.
> That's a lot of work.
>
> I feel like introducing TSVarLenData has more downside than the upside.
>
> On Wed, Jan 4, 2023 at 9:13 AM Walt Karas <wka...@yahooinc.com.invalid>
> wrote:
>
> > They could make the returned structure a nesting structure in their
> > structure.  Better to make things more convenient for the typical case,
> not
> > the unusual case.
> >
> > On Tue, Jan 3, 2023 at 12:28 PM Masakazu Kitajo <mas...@apache.org>
> wrote:
> >
> > > What's the benefit of forcing users to use the structure? A user might
> > want
> > > to store the returned pointer into a user-defined structure.
> > >
> > >
> > >
> > > On Tue, Sep 6, 2022 at 10:24 AM Walt Karas <wka...@yahooinc.com.invalid
> >
> > > wrote:
> > >
> > > > Presumably we don't need to allow for use of antiquated C compilers
> > that
> > > > don't allow structures as return values.  So this:
> > > >
> > > > typedef struct
> > > > {
> > > > char *data;
> > > > int length;
> > > > }
> > > > TSVarLenData;
> > > >
> > > > TSVarLenData TSSomething(x, y, z);
> > > >
> > > > Is another alternative.
> > > >
> > > > On Thu, Sep 1, 2022 at 5:32 PM Masakazu Kitajo <mas...@apache.org>
> > > wrote:
> > > >
> > > > > Using encapsulation/data abstraction is fine, but it doesn't seem
> > like
> > > > > TSHeapBuf makes sense. No TS API receives it. If plugin code is the
> > > only
> > > > > user and it has to deal with a non-const raw pointer and a data
> > length
> > > > > after all, why do we want to wrap them in the first place?
> > > > >
> > > > > As for smaller steps, like I suggested on the PR, you could
> introduce
> > > > > TSHeapBuf separately from the fix, I think. And if there are
> similar
> > TS
> > > > > APIs that could return TSHeapBuf, supporting TSHeapBuf on only one
> of
> > > > them
> > > > > makes inconsistency in TS API. IMO, the two changes, the fix and
> the
> > > new
> > > > > API, should be made like 1 + 1, but not 1.5 + 0.5 nor 1 + 0.5 +
> 0.5.
> > > > >
> > > > > Masakazu
> > > > >
> > > > > On Thu, Sep 1, 2022 at 10:08 AM Walt Karas
> > <wka...@yahooinc.com.invalid
> > > >
> > > > > wrote:
> > > > >
> > > > > > As a rule of thumb, I prefer using encapsulation/data
> > abstraction.  I
> > > > > think
> > > > > > perhaps that is one reason I've been a poor match to this
> project.
> > > > There
> > > > > > doesn't seem to be a consensus that  we should follow this rule
> of
> > > > thumb.
> > > > > >
> > > > > > KIt, that would be my preference.  But I am part of the
> consensus I
> > > > think
> > > > > > we have, that we should favor a series of smaller steps, rather
> > than
> > > > > doing
> > > > > > all of them in one big step.
> > > > > >
> > > > > > On Wed, Aug 31, 2022 at 12:13 PM Shu Kit Chan <
> > chanshu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Also are we planning to eventually rewrite our existing APIs
> > (where
> > > > > > > applicable) to use this?
> > > > > > >
> > > > > > > On Wed, Aug 31, 2022 at 8:36 AM Masakazu Kitajo <
> > mas...@apache.org
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > What's the advantage of using TSHeapBuf? What issue does it
> > > solve?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Aug 31, 2022 at 7:48 AM Walt Karas
> > > > > <wka...@yahooinc.com.invalid
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Described here:
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/trafficserver/blob/os_pkey_cnf_reload/doc/developer-guide/api/functions/TSHeapBuf.en.rst*tsheapbufdata__;Iw!!Op6eflyXZCqGR5I!Du0fBfMhb4pdM2ECFijJ7aJ-jT70jEPeZwjhsvWt2Dr2cSZ5G7HWY20wZOmFHIR3MxnvPZpoRDMlII5dgow$
> > > > > > >
> > > > > > > > > ,
> > > > > > > > >
> > > > > > > > > In PR
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/trafficserver/pull/8790__;!!Op6eflyXZCqGR5I!Du0fBfMhb4pdM2ECFijJ7aJ-jT70jEPeZwjhsvWt2Dr2cSZ5G7HWY20wZOmFHIR3MxnvPZpoRDMlYh9lIuc$
> > > > > > >  .
> > > > > > > > >
> > > > > > > > > This allows a dynamically allocated buffer, of any
> reasonable
> > > > > length,
> > > > > > > to be
> > > > > > > > > returned by a TS API function, like this:
> > > > > > > > >
> > > > > > > > > TSHeapBuf hb = TSSomething(x, y, z);
> > > > > > > > >
> > > > > > > > > One alternative is an interface like this:
> > > > > > > > >
> > > > > > > > > int length;
> > > > > > > > > char *data = TSSomething(x, y, z, &length);
> > > > > > > > >
> > > > > > > > > The data is dynamically allocated, and would be freed with
> > > > > TSfree().
> > > > > > > > >
> > > > > > > > > Another alternative is:
> > > > > > > > >
> > > > > > > > > char *buf = TSalloc(BUF_SIZE);
> > > > > > > > > int actual_size = TSSomething(x, y, z, buf, BUF_SIZE);
> > > > > > > > > if (actual_size > BUF_SIZE) {
> > > > > > > > >   // buf was too small, unchanged.
> > > > > > > > >   TSfree(buf);
> > > > > > > > >   buf = TSalloc(actual_size);
> > > > > > > > >   TSSomething(x, y, z, buf, actual_size);
> > > > > > > > > }
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to