From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103])
 (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 0F24E469710
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 14 May 2020 05:24:28 +0300 (MSK)
Date: Thu, 14 May 2020 02:24:28 +0000
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20200514022428.GD18509@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5c933d26-cda8-81e1-30f6-3547a4629b31@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 13 May 23:48, Vladislav Shpilevoy wrote:
> Hi! 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.

> This is a JSON value (even though it is
> not considered standard). Msgpuck prints it, when does not know what else
> do with the type.
 
> This was the case for all MP_EXT so far, they were printed as 'undefined'.
> Now only unknown are 'undefined'.