× 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.



Ok, I think I get it now. :)

If I pass a size into yajl_get_string_buf() then where would the cleanup
happen?

The way I'm doing it now, I do the cleanup after I'm done working with it.
So, for each JSON element I allocate the space, do my work with the data,
then deallocate the space.

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

So, I think we have similar ideas, but different methods.

Brad
www.bvstools.com

On Mon, May 23, 2016 at 3:16 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

Oh hey, Brad, your page
(http://www.fieldexit.com/forum/display?threadid=321) shows this:

data@ = %alloc(MAX_SIZE);

So, you do have *some* kind of limit, and that limit is known in the
calling RPG before you do

rc = yajl_get_string_buf(val:data@);

It's pretty darn big in 7.1 (docs say 4GB if teraspace is used).
Presumably that's enough. So, to make your call compatible with
Scott's version of YAJL_GET_STRING_BUF() (note that he said he agreed
with you on returning the string length), wouldn't you just do

rc = yajl_get_string_buf(val:data@:MAX_SIZE);

?

If that suffices for your needs, then I retract my earlier idea of
including both versions (yours and Scott's) and endorse Scott's
(caller passes pointer to pre-allocated buffer; procedure returns the
string length instead of just a flag).

Or do you have another way to call it which really does need fully
dynamic operation?

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 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.