Re: int8_t vs size_t

of now, arrow doesn't even compile in 32 bit. I can fix it, but has the decision been made to stop supporting it? Thanks, Arkadiy From: dev@arrow.apache.org At: 06/08/22 13:38:43 UTC-4:00To: dev@arrow.apache.org Subject: Re: int8_t vs size_t Hi, It is a conscious decision of followin

Re: int8_t vs size_t

38:43 UTC-4:00To: dev@arrow.apache.org Subject: Re: int8_t vs size_t Hi, It is a conscious decision of following the Google C++ style guide: https://google.github.io/styleguide/cppguide.html#Integer_Types I agree that size_t (or ssize_t) would have been a better choice for in-memory length

Re: int8_t vs size_t

Hi, It is a conscious decision of following the Google C++ style guide: https://google.github.io/styleguide/cppguide.html#Integer_Types I agree that size_t (or ssize_t) would have been a better choice for in-memory lengths and sizes. Unfortunately, that ship has sailed now. 32-bit systems a

int8_t vs size_t

Hi all. Throughout the entire project, int64_t rather than size_t is consistently used to denote size and offset. This causes massive amount of compiler warnings in the 32 bit system. Is it an oversight or a conscious design decision? If latter, what is the reason behind it? Thanks, Arkadiy