> 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);
> > > > > > > > }
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
