I'm reading https://www.sqlite.org/src/artifact/529255dc70428900, and stumbled on:
** For FLOAT values, the content is the IEEE754 floating point value in ** native byte-order. This means that FLOAT values will be corrupted when ** database file is moved between big-endian and little-endian machines. And my immediate reaction is why? SQLite DBs are portable themselves. Why make the decision to break that portability when using the LSM1 extension? I strongly suspect SQLite4, which also uses LSM, uses a portable encoding for row data (the contrary would be extremely surprising), so why go for non-portability on that one datatype, instead of 1) encoding the endianness in the type, or 2) forcing a given endianness, or 3) using varints to encode the mantissa and exponent, therefore providing the platform portability? Thanks, --DD PS: typo: varaible-length PPS: Is the SQLite4 varint encoding ( https://sqlite.org/src4/doc/trunk/www/varint.wiki) different from the SQLite3 one? _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
