From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtp51.i.mail.ru (smtp51.i.mail.ru [94.100.177.111])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 01067469710
 for <tarantool-patches@dev.tarantool.org>;
 Tue, 19 May 2020 16:23:04 +0300 (MSK)
Date: Tue, 19 May 2020 13:23:04 +0000
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20200519132304.GC12739@tarantool.org>
References: <cover.1589240704.git.v.shpilevoy@tarantool.org>
 <9dd79b8d7c37a9ff60e4c7abcde81c5cf5b4e5f6.1589240704.git.v.shpilevoy@tarantool.org>
 <20200513210633.GA18509@tarantool.org>
 <5c933d26-cda8-81e1-30f6-3547a4629b31@tarantool.org>
 <20200514022428.GD18509@tarantool.org>
 <a52f0854-6130-349f-868c-d1297e3a8df8@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <a52f0854-6130-349f-868c-d1297e3a8df8@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH 5/5] msgpuck: activate MP_EXT custom
	serializers
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

On 14 May 23:27, Vladislav Shpilevoy wrote:
> Thanks for the review!
> 
> >> On 13/05/2020 23:06, Nikita Pettik wrote:
> >>> On 12 May 01:45, Vladislav Shpilevoy wrote:
> >>>> +
> >>>> +static int
> >>>> +msgpack_fprint_ext(FILE *file, const char **data, int depth)
> >>>> +{
> >>>> +	int8_t type;
> >>>> +	uint32_t len = mp_decode_extl(data, &type);
> >>>> +	switch(type) {
> >>>> +	case MP_DECIMAL:
> >>>> +		return mp_fprint_decimal(file, data, len);
> >>>> +	case MP_UUID:
> >>>> +		return mp_fprint_uuid(file, data, len);
> >>>> +	case MP_ERROR:
> >>>> +		return mp_fprint_error(file, data, depth);
> >>>> +	default:
> >>>> +		return fprintf(file, "undefined");
> >>>
> >>> I'd come up with more sensible message in case of "undefined" mp_ type.
> >>> For instance: ("undefined mgpack extension (%d)", type).
> >>
> >> This is not an error message.
> > 
> > I understand that. Still I stick to the point that simple "undefined"
> > looks poor.
> 
> Ok, I just noticed that you wrapped your proposal into (). It is not just
> a bare string or something else, that could be treated in 2 ways. Then I
> guess it is ok. Anyway both 'undefined', and parenthesis are JS JSON parsers
> features only. So by adding a few details we are not breaking normal JSON
> parsers any further.
> 
> I changed this commit, and added a new commit to the msgpuck patchset.
> The message is changed a little.
> 
> ====================
> diff --git a/src/box/msgpack.c b/src/box/msgpack.c
> index 37bb3920c..4013aec4c 100644
> --- a/src/box/msgpack.c
> +++ b/src/box/msgpack.c
> @@ -49,7 +49,8 @@ msgpack_fprint_ext(FILE *file, const char **data, int depth)
>  	case MP_ERROR:
>  		return mp_fprint_error(file, data, depth);
>  	default:
> -		return fprintf(file, "undefined");
> +		return fprintf(file, "(extension: type %d, len %u)", (int)type,
> +			       (unsigned)len);
>  	}
>  }
>  
> @@ -66,7 +67,8 @@ msgpack_snprint_ext(char *buf, int size, const char **data, int depth)
>  	case MP_ERROR:
>  		return mp_snprint_error(buf, size, data, depth);
>  	default:
> -		return snprintf(buf, size, "undefined");
> +		return snprintf(buf, size, "(extension: type %d, len %u)",
> +				(int)type, (unsigned)len);
>  	}
>  }
>  

LGTM.