> On 20 Aug 2018, at 15:15, Adis Nezirovic <aneziro...@haproxy.com> wrote:
>
> On Mon, Aug 20, 2018 at 02:11:13PM +0200, Adis Nezirovic wrote:
>> Hi guys,
>>
>> I've attached a patch to add stick table support to Lua. Operations are
>> mostly similar to "show table" functionality from admin socket, namely:
>>
>> - Show basic table info
>> - Key lookup
>> - Table dump, optionally using data/column filter
>>
>> One side note, the code provides support for multiple filters
>> (4 by default) while CLI doesn't support that, nor it complains about
>> multiple "<data.type> <op> <val>" clauses.
Hi Adis,
This is a great feature. I look this ASAP.
>> Also, if this patch is accepted, maybe we can use provided helper
>> functions in other places in the code.
>>
>
> It's always funny to reply to self, right sending email to public I've
> spotted a bug. New patch attached.
>
> SMT_T_SINT should be treated as ordinary signed integer, and shoud use
> lua_pushinteger() on it?
There are a function which convert haproxy type in Lua types: hlua_arg2lua(),
and SINT is converted with lua_pushinteger(). I guess that stick tables SINT
are the same.
> On many places in the code it is noted as "64" bit integer, but in
> stick_table.c it is defined as 32bit integer:
>
> struct stktable_type stktable_types[SMP_TYPES] = {
> [SMP_T_SINT] = { "integer", 0, 4 },
The lua_pushinteger function takes a lua_Integer which is defined as known C
type (int, long or long long). So, when the function lua_pushinteger() is
called, the compilator perform a conversion between the type passed as argument
and the expected type. So I’m confident with the good behavior.
br,
Thierry
> Best regards,
> Adis
> <0001-MEDIUM-lua-Add-stick-table-support-for-Lua-read-only.patch>
