[tarantool-patches] Re: [PATCH] box: add tuple:size function

[Vladislav Shpilevoy]

In addition, a function, returning some internal size
that can not be applied to any user code object, is
useless except statistics.

So box_tuple_bsize will be useless.

On 17/10/2018 21:06, Vladislav Shpilevoy wrote:
> 
> 
> On 17/10/2018 18:29, Konstantin Osipov wrote:
>> * Alexander Turenko <alexander.turenko at tarantool.org> [18/10/17 10:45]:
>>> Are tuple.bsize and box_tuple_bsize() subjects to change or it is only
>>> about the Lua part?
>>
>> tuple.bsize is used internally, so I don't think you should change
>> it. But it's better to rename it to msgpack_size or something like
>> that to avoid ambiguity.
>>
>> box_tuple_bsize() should be ok to change.
>>
> 
> box_tuple_bsize() is already documented in module.h as
> returning only tuple data.
> 
> Also, some people can use it right now to allocate a
> buffer of a correct size before calling box_tuple_to_buf.
> I understand, that box_tuple_to_buf(tuple, NULL, 0) returns
> bsize as well, but some people could miss it, or just use
> box_tuple_bsize because it looks better when you write like
> this:
> 
>      size = box_tuple_bsize(tuple)
>      buf = alloc(size)
>      box_tuple_to_buf(tuple, buf, size)
> 
> than like this:
> 
>      size = box_tuple_to_buf(tuple, NULL, 0) // <- difference
>      buf = alloc(size)
>      box_tuple_to_buf(tuple, buf, size)
> 
> Even if we close eyes on the fact, that a user of
> the first way will allocate more data than needed,
> imagine, that then he does something like this:
> 
>      send(sockfd, buf, size)
> 
> Now, he send some garbage uninitialized data of 14
> bytes at the end of buf.
> 
> I understand, that you likely not believe me that
> the first way looks more intuitive, but look at
> our own code: box_tuple_bsize() is used now in
> 
> *box/lua/tuple.c in tuple_to_mpstream();
> * box/lua/tuple.lua via FFI;
> 
> to allocate a buffer before copying tuple data
> directly or via tuple_to_buf. We can fix our code,
> but can not fix user's one.
> 
> So here we can either
> 
> * fix documentation of the site without breaking anything
> * or break behavior of public API destroying an ability to
>    learn tuple data size in a natural way;
> * add new method and again fix the site documentation.
> 
> I described it just for the record that you have chosen
> the second, most destructive way.
> 
>