It should be preferred instead of Data:getPointer because the latter uses lightuserdata which can't store more all possible memory addresses on some new arm64 architectures, when LuaJIT is used.
The C++ code already threw an exception when creating a DataView with size 0, but the corresponding lua wrapper ignored it. Now it's correctly turned into a lua error.
Silence compiler warnings about methods with return value and potentially not returning anything.
This happens with gcc8 and the `-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -std=c++11` flags passed to it by default on openSUSE.
All enum errors have (hopefully) been changed to a luax_enumerror, which has a
fixed error message. If additionally a list of valid options is passed, it
lists that in the error message. For every enum error with few options I've
implemented this using a getConstants call.
This solution has been designed specifically to reduce the number of template
instantiations (as I've been told that was a concern). All new template code
happens in places where there already was an instantiation of the relevant
StringMap. Of course there is still std::vector<std::string>...
--HG--
branch : minor
- Moved love.math.compress / decompress / decode / encode / hash to love.data.
- Changed love.data.compress/decompress to take the format argument first instead of second.
- Added love.data.newDataView. Returns a read-only subsection of an existing Data object.
- Added love.data.newByteData. Mostly useful in combination with LuaJIT's FFI as it has no extra methods currently.
- Added implementations of Lua 5.3's data packing APIs: love.data.packString / packData / unpack / getPackedSize.
Resolves issue #1336.
Resolves issue #1331.
--HG--
branch : minor
Alex Szpakowski
Bart van Strien
Pablo Mayobre
Michael Vetter