On the mac I’m 100% sure the 2 values are treated as 64 bits values
is it the same on Win10 and Linux ? (probably compiler dependent)
(asking because I suspect some wrong behaviour on my PolyREC is happening for this, with files bigger that 2^32)
(it’s easy to have a pcm file bigger than 4Gb: 2 minutes, 64 track, 32 bit float samples, 192kHz)
anyway now I’ve changed everywhere to unsigned long long
Good question. On the compilers Rack uses, long is 4 bytes (32 bits) on Windows x86_64 and 8 bytes (64 bits) on Mac/Linux x86_64.
Therefore you should never use the long keyword, because there is no situation imaginable where you need an integer type that’s 4 bytes on Windows and 8 bytes on Mac/Linux (and if you do, you should be more explicit about this unusual requirement with #if defined ARCH_WIN blocks).
If you care about the size of an integer type, use the explicit types in cstdint, e.g. uint64_t, int64_t, uint32_t, etc. If you don’t care about the size (if you know you only need to count to 1000 or so), use int, which is 32-bit on all compilers Rack uses.
You will never see me use the keywords long, short, and unsigned in Rack code because they suggest that I do care about the type of an integer, in which case I should be using the cstdint types instead. It is better to forget those keywords exist.
you probably shouldn’t be using long or long long or int these days, they’ve never been truly defined other than compiler “helpers” (it’s like counting in char being signed or unsigned, who knows?). c and c++ have both moved past it and have specific bit sized variable types:
yup, it’s a nice one - I guess it helps since register seems to be deprecated. it is definitely helpful for math … not that any of us is really doing much math though, right?