lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

2016-12-03 12:44 GMT+01:00 Pierre Chapuis <>:
> December 3, 2016 12:37 AM, "Sean Conner" <> wrote:
>> I found the API itself interesting. When I wrote my CBOR module [1] I
>> check the strings and if they pass as a UTF-8 string, I encode the string as
>> TEXT; otherwise it gets encoded as BIN. It never occured to me to have a
>> function set the default behavior, and I wonder how your method would work
>> with a table of mixed strings and binary data (or is that even enough of a
>> concern to conern yourself with? I don't know ... ).

I don't like the idea : the encoding format depends on the value,
for example in RFC 7049, section 3.9.  Canonical CBOR
> If a protocol allows for IEEE floats, then additional
> canonicalization rules might need to be added.  One example rule
> might be to have all floats start as a 64-bit float, then do a test
> conversion to a 32-bit float; if the result is the same numeric
> value, use the shorter value and repeat the process with a test
> conversion to a 16-bit float.  (This rule selects 16-bit float for
> positive and negative Infinity as well.)  Also, there are many
> representations for NaN.  If NaN is an allowed value, it must always
> be represented as 0xf97e00.

this kind of behaviour is
- slow (because it tries various ways),
- not easy to test (because many special cases occur)

with few functions (set_string, set_number, set_nil, set_array),
you could config the encoding at your application level.
For example, with an application which is a sensor,
you could encode float number always with 16-bits,
because you know that this precision is enough.


>> You do a similar thing with arrays, but it's rather terse about the
>> 'with_hole' option---how does that work? Does the code in that case look
>> for a field 'n' in the table? I just assume if a table has a length
>> defined, it's encoded as an ARRAY; otherwise a MAP (and because of that, an
>> empty table is encoded as a MAP).
> You can probably do the same thing as with his MessagePack library:
> use the function packer to encode anything.
> See
> for the details. Maybe a similar section should be added to the CBOR
> module documentation as well.
> --
> Pierre Chapuis