[Tarantool-patches] [PATCH 1.10 7/9] RFC: module api: extend list of public symbols in 1.10

[Alexander Turenko]

> diff --git a/extra/exports b/extra/exports
> index a4ac03530..70b59a0a6 100644
> --- a/extra/exports
> +++ b/extra/exports
> @@ -118,7 +118,10 @@ coio_call
>  coio_getaddrinfo
>  luaL_pushcdata
>  luaL_iscdata
> +luaL_iscallable

It should be part of relevant commits (just like on your 2.x branch).
The same for the other functions.

Or you may have one commit for backport (just cherry-pick) and a
separate commit with \public cond + exports.

> +mp_char2escape
> +mp_decode_extl
> +mp_ext_hint
> +mp_format
> +mp_fprint
> +mp_parser_hint
> +mp_snprint
> +mp_type_hint
> +mp_vformat

Those functions are not used in merger. It seems you want to overcome
some linking problem. At least, please, explain this change.

Anyway, including msgpuck headers and using symbols from tarantool looks
dangerous. Maybe we can just expose necessary mp_*() functions into box
api: both to headers and to public symbols, as we usually do?

I looked, the list is not large: mp_next(), mp_check(), mp_store_u32(),
mp_typeof(), mp_check_array(), mp_decode_array(), mp_sizeof_array(),
mp_encode_array() and MP_ARRAY constant.

Alternative: bundle msgpuck into the module, but tweak it to be header
only back (add some ifdefs). This way, I guess, it would be safe to use
external msgpuck and don't bother about symbol names clash (need to
verify, though). At least if mp_next() / mp_check() successfully
traverse over unknown mp_ext (I guess it is so) and you don't need to
parse specific mp_ext types. It'll be enough for most use cases I guess.