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