Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88587
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20150930205857.GA93503@3006.local>
References: <CADbOR2hf_eDzRdMWuKs5imn3PDbBo52Fm62=ShDOt49H_gpmbw@mail.gmail.com>
	<20150930205857.GA93503@3006.local>
Date: Wed, 30 Sep 2015 14:11:59 -0700
Message-ID: <CADbOR2gSZGCLv2sGUDmCJGm3J7FEkxwNH3sMfHuO6CbGfMXyMg@mail.gmail.com>
To: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ff20e94c3a70520fd6163
Subject: Re: [PHP-DEV] good example of unserialization fundamentals?
From: zardozrocks@gmail.com (j adams)

--001a113ff20e94c3a70520fd6163
Content-Type: text/plain; charset=UTF-8

Thanks for your response. I do follow the concept of macros (and my IDE
expands them for me if I need), however, I just want to confirm that it's
OK to be using these in a *recursive function*? I'm aware from S. Golemon's
book that these (deeply nested) macros also have the effect of incrementing
refcounts and such. For instance, I'm sure the RETURN_* macros will break
your code if you don't have a zval *return_value defined in the current
scope. Are there other caveats or heuristic rules to avoid abusing these
macros?

OH, and perhaps I forgot to ask with my original post. Can anyone point me
to a good example of a function that takes some userland input and
recursively interprets it as possibly nested arrays or objects? I've been
looking at php_json_decode_ex[0] but it is allocating and freeing memory
for utf16/8 converters and JSON_Parser_structs and so on.


[0] http://lxr.php.net/xref/PHP_5_6/ext/json/json.c#683

On Wed, Sep 30, 2015 at 1:58 PM, Sean DuBois <sean@siobud.com> wrote:

> On Wed, Sep 30, 2015 at 01:39:26PM -0700, j adams wrote:
> > I have completed a first draft of serialization functionality which is
> > intended to be an updated to amfext. It's on github[0] if anyone is
> > interested. I would now like to write all the unserialization routines
> and
> > would like some suggestions from experienced php devs. I've been reading
> > Sara Golemon's book, but am still a little unsure.
> >
> > In particular, I want my userland function, amf_decode to accept as a
> > parameter a string (and possibly other args). This is not so difficult
> but
> > I must call upon another function, php_amf_decode, which needs to be able
> > to handle recursive calls.
> >
> > Something like this:
> >
> > // userland function
> > static PHP_FUNCTION(amf_decode) {
> >     char *buf; // char buffer, contains serialize data string
> >     int buf_len, buf_cursor=0; // the length of the buffer
> >     long flags = 0;
> >
> >     if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s|l", &buf,
> > &buf_len, &flags) == FAILURE) {
> >         return;
> >     }
> >
> >     if (!buf_len) {
> >         RETURN_NULL();
> >     }
> >
> >     php_amf_decode(return_value, buf, buf_len, &buf_cursor, flags
> > TSRMLS_CC);
> > }
> >
> > // proposed recursive decoding function
> > PHP_AMF_API void php_amf_decode(zval *return_value, char *buf, int
> buf_len,
> > int *buf_cursor, long flags TSRMLS_DC)
> > {
> >
> >     // is it safe to use these macros in this recursive function?
> >     RETVAL_BOOL(1);
> >
> >     // or this
> >     RETURN_LONG(42);
> >
> >
> > }
> >
> >
> > [0] https://github.com/sneakyimp/amfext
>
> Yep those are safe!
>
> RETVAL_* expands out so you don't have to repeat the variable
> `return_value`
>     ZVAL_LONG(return_value, l)
>
> RETURN_* expands out so you don't have to call return OR specify the
> variable `return_value`
>    ZVAL_LONG(return_value, l)
>    return;
>
> Here they are in 5.6 http://lxr.php.net/xref/PHP_5_6/Zend/zend_API.h#618
> ---
>
> A great tool to look these things up quickly is lxr, sure beats grep!
>
> http://lxr.php.net/search?q=&defs=RETURN_LONG&refs=&path=&hist=&project=PHP_5_6
>

--001a113ff20e94c3a70520fd6163--