From: Vladimir Davydov <vdavydov.dev@gmail.com> To: Serge Petrenko <sergepetrenko@tarantool.org> Cc: tarantool-patches@freelists.org, georgy@tarantool.org, kostja@tarantool.org Subject: Re: [PATCH v3] Add MsgPack ext types handling. Date: Tue, 4 Jun 2019 17:11:53 +0300 [thread overview] Message-ID: <20190604141153.63z7yefi2uituyw3@esperanza> (raw) In-Reply-To: <20190603131425.29405-1-sergepetrenko@tarantool.org> On Mon, Jun 03, 2019 at 04:14:25PM +0300, Serge Petrenko wrote: > diff --git a/msgpuck.c b/msgpuck.c > index d0ffb83..e5f7e25 100644 > --- a/msgpuck.c > +++ b/msgpuck.c > @@ -33,6 +33,17 @@ > #define MP_LIBRARY 1 > #include "msgpuck.h" > > +const char * > +mp_ext_type_str(enum mp_ext_type type) > +{ > + switch(type) { > + case MP_EXT_TIMESTAMP: > + return "timestamp"; > + default: > + return "undefined"; > + } > +} > + > size_t > mp_vformat(char *data, size_t data_size, const char *format, va_list vl) > { > @@ -298,9 +309,14 @@ next: \ > PRINTF("%lg", mp_decode_double(&data)); \ > break; \ > case MP_EXT: \ > - mp_next(&data); \ > - PRINTF("undefined"); \ > + { \ > + int8_t type; \ > + uint32_t len; \ > + len = mp_decode_extl(&data, &type); \ > + PRINTF("%s", mp_ext_type_str(type)); \ > + data += len; \ > break; \ > + } \ It isn't exactly helpful to see "timestamp" instead of a timestamp value. If we add MP_EXT_TIMESTAMP to the library, we should implement all methods needed to work with it: mp_sizeof_timestamp mp_encode_timestamp mp_decode_timestamp mp_vformat mp_snprint Since this would require a lot of effort and is out of the scope of this issue, I suggest dropping MP_EXT_TIMESTAMP altogether for now. Let's just simply add mp_ext infrastructure, like you did in this patch. In tests, you can pass an arbitrary number for MP_EXT type. > +/** > + * \brief Encode extension data of length \a len. > + * The function is equivalent to mp_encode_extl() + memcpy. > + * \param data - a buffer > + * \param ext_data - a pointer to extension data > + * \param type - extension type to encode > + * \param len - a extension data length > + * \return \a data + mp_sizeof_ext(\a len) == > + * data + mp_sizeof_extl(\a len) + \a len > + * \sa mp_encode_strl > + */ > +MP_PROTO char * > +mp_encode_ext(char *data, char *ext_data, int8_t type, uint32_t len); Nit: - IMO 'type' should go before 'ext_data' in the argument list as it defines what 'ext_data' is about. - I'd rename 'ext_data' argument to 'str' for consistency with mp_encode_bin/str. Besides, it's shorter. Not really important so this one is up to you. Other than that, the patch looks good to me.
next prev parent reply other threads:[~2019-06-04 14:11 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-03 13:14 Serge Petrenko 2019-06-04 14:11 ` Vladimir Davydov [this message] 2019-06-04 15:24 ` [tarantool-patches] " Serge Petrenko 2019-06-04 15:40 ` Vladimir Davydov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190604141153.63z7yefi2uituyw3@esperanza \ --to=vdavydov.dev@gmail.com \ --cc=georgy@tarantool.org \ --cc=kostja@tarantool.org \ --cc=sergepetrenko@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [PATCH v3] Add MsgPack ext types handling.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox