> 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." 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. 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. IMNSHO, of course. -- M -- 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/1409639996.22494.72.camel%40AVA-381075. For more options, visit https://groups.google.com/d/optout.
