|
On Mon, May 23, 2016 at 4:52 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:Good points. Passing in an address to a variable would make it more
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.)
Another good point, John. I didn't think about reusing the same memory.If I call this 100 times (passing in a size and not allocating anda
deallocating) and the cleanup doesn't happen until the end that could be
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.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
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.