× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Mon, May 23, 2016 at 4:52 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:
If I pass a size into yajl_get_string_buf() then where would the cleanup
happen?

I know that was asked in a rhetorical, I'm-about-to-answer-it-myself
kind of way, but I'll elaborate anyway: I would think that
yajl_get_string_buf() cannot do any cleanup itself, regardless.
Whether the space is allocated by the caller ahead of time or by the
called procedure, the buffer cannot be cleared before the caller has a
chance to read what's in it. So the cleanup must happen outside
yajl_get_string_buf().

I think the choices are: (1) If the caller did %alloc(), then the
caller has to do %dealloc(). (2) If the caller just used an RPG
character variable (and passed a pointer to THAT), then the RPG
"runtime" handles the cleanup. (Anything else like user spaces ought
to be a variation on one of those.)

If I call this 100 times (passing in a size and not allocating and
deallocating) and the cleanup doesn't happen until the end that could be a
LOT of allocated space. And right now the only cleanup I see is
deallocating the main tree using yajl_tree_free(node);

Um... if you're passing the same pointer (let me be clear: passing in
the same memory address) each time, then I would think you're not
allocating more and more space, but reusing the same space (or at most
the space needed by the largest size you've passed in). But yes, if
you get a new address for a new allocation each time, then you
probably could be using more and more memory.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.