Closed samuelpowell closed 4 years ago
This is a known bug. See pull request #16. 64 bit support requires fixing the _l functions.
Got it, thank you for the prompt response @mgrivich. I will guard these functions for now.
@samuelpowell I invite you to weigh in on #16 because they appear to be at a bit of a stalemate. If anything it will keep the discussion fresh and moving forward.
I am currently finishing up an LSL wrapper for Julia (https://github.com/samuelpowell/LSL.jl) which is based on an autogenerated wrapper of your C API. The library is cross compiled for lots of different architectures (https://github.com/samuelpowell/LSLBuilder) and things are working well on Linux (x64) and Mac, and we're about to test ARMv7 and ARMv8 support.
I have a query regarding data types: I note that
liblsl
usesint
andlong
(e.g.lsl_push_sample_i
andlsl_push_sample_l
).On 32-bit UNIX like architectures, both data types are 32-bits. Does this mean that you do not support 64-bit integer channels on 32-bit architectures?
On 32- and 64-bit Windows both data types are 32-bits. Does this mean there is no support whatsoever for 64-bit integer channels on Windows?
It may be that you are doing some sort of preprocessor magic to redefine the
_l
suffixed functions to beint64_t
, but I couldn't find that. Any clarifications helpful such that I can guard the wrapper function by architecture.