On 2014-02-09 8:39, markus wrote:

Most serialization formats can simply not deal with > 64 bit values as
regular numbers. They may do horrible things like truncation, or use
the max/min value if a value is too big, or for floating point
drastically lose precision.

Eh.  It's not that the serialization formats can't deal with or do
horrible things to >64 bit values, but that some languages that don't
support high precision numbers implement the formats awkwardly.

This isn't just a problem with serialization, or with >64 bit values.
Languages that don't implement math well tend to have all sorts of
problems.

For example, in javascript (I just tested on nodejs, but others have
similar issues), the 56 bit integer 0xffffffffffffff is even (nodejs
thinks it's 72057594037927940) whereas in ruby, C, python, etc. it's odd
(72057594037927935).  Since the later value is also what you get from
math, I think it would be safe to call the first answer "wrong."

After 2^53 Javascript loses precision since it becomes floating point.

These sorts of cases abound.

If you're going to treat this as a problem with the puppet's
serialization, by setting caps and having puppet "fail" on results that
some other languages may choke on, I suspect you'll wind up discovering
that the lowest common denominator is uncomfortably low.  There's still
some code out that thinks an integer means 16 bits, but the correct
response is to be cautious of such islands of math-fail, rather than
restricting the rest of the world to their limitations.

There are naturally lots of crappy software with problems in this area.
I did look at the main implementations for MsgPack, JSON, and YAML.
Currently, even Puppet itself will not work correctly with values over 2^63-1 or smaller than -2^63 when such values are stored in PuppetDB. If we were to change that, we would sacrifice on performance for every normal case (where integers fit in 64 bits).

A better path would be to 1) make sure puppet's results are
mathematically correct, and 2) warn people about cases where where using
code in other languages could lead to problems.

We will do math as good as the underlying implementation language allows us. The value at the edge though, when assigned to an attribute that will be serialized and stored in the DB needs to fit an Integer.

Cannot really do much about 2, it is a language/implementation thing and we simply cannot look at every such combination.

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/lu4k83%245sa%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to