| ▲ | eska 3 days ago |
| Not sure whether this is tested on Windows at all. I opened the header and immediately found this `typedef signed long i64`, i.e. i64 is actually i32. |
|
| ▲ | bluecalm 3 days ago | parent | next [-] |
| This is strange because C99 has stdint.h so we don't need to use "short/long/long long/long long long" nonsense anymore. |
|
| ▲ | colleagueRiley 3 days ago | parent | prev | next [-] |
| I test Windows mainly with MINGW, that might be an issue with MSVC. Feel free to report the issue on the github repository. I'm pretty sure windows uses "long" for 64 bit but linux uses "long long" for 64 bit |
| |
| ▲ | flohofwoe 3 days ago | parent | next [-] | | Since you're using C99 as the base C version, why not use the fixed-width types from stdint.h (int32_t, int64_t, ...)? You can still typedef those to i32, i64 shortcuts etc, but I would try to avoid this in libraries since it might collide with user typedefs of the same name - or at least try to avoid it in the public API declarations. | | |
| ▲ | colleagueRiley 3 days ago | parent [-] | | I use those by default although I read that MSVC's support for those are iffy. I'm pretty sure STB does the same thing for the same reason. Source: https://handmade.network/forums/articles/t/7138-how_to_write... | | |
| ▲ | flohofwoe 3 days ago | parent [-] | | Since around Visual Studio 2015 you're fine. AFAIK the STB headers are on C89 mainly because nothings likes to use VC6 as C IDE. E.g. if you depend on other C99 features anyway, including stdint.h is fine, also on MSVC. PS: FWIW I use stdint.h types in the Sokol headers since around 2017 and never heard complaints from users, with the supported compilers being MSVC, GCC and Clang. | | |
| ▲ | eska 3 days ago | parent | next [-] | | Since around Visual Studio 2015 you're fine. I personally use `_MSC_VER >= 1600`, so it's since Visual Studio 2010 from April 2010. Built-in types like __int32 from before then may be used as well. | |
| ▲ | colleagueRiley 3 days ago | parent | prev [-] | | Oh, I wasn't sure if that was you :) Thanks for the advice, I'm a little worried about breaking compatibility with compilers that don't support stdint. But if it's standard for C99 thing then sure. |
|
|
| |
| ▲ | tredre3 3 days ago | parent | prev | next [-] | | > I'm pretty sure windows uses "long" for 64 bit but linux uses "long long" for 64 bit Windows long is 32bit even on 64bit CPUs. Linux long is arch dependent and is 64bit on x64, 32bit on x86. long long is always 64bit on both platforms. | | | |
| ▲ | eska 3 days ago | parent | prev | next [-] | | It's just that the #if checks for the MSVC compiler, not for Windows as a platform. And on that compiler you will never have LP64, but LLP64: https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_m... I just roll my own for this because I don't need all the functionality, and generally find such cross-platform libraries to only really test on Linux, and it's too much of a hassle. | | | |
| ▲ | Iwan-Zotow 2 days ago | parent | prev [-] | | > I'm pretty sure windows uses "long" for 64 bit but linux uses "long long" for 64 bit other way around |
|
|
| ▲ | InfiniteRand 3 days ago | parent | prev | next [-] |
| It depends whether you're compiling in 32-bit or 64-bit mode, MSVC has two different modes and there are different versions of MinGW for 32-bit and 64-bit |
| |
|
| ▲ | Conscat 3 days ago | parent | prev [-] |
| I'm not sure that issue would be caught by ordinary testing. It will implicitly cast into long long, so it might make little or no difference in this case. |
| |
| ▲ | eska 3 days ago | parent [-] | | A lot of people use i64 in the global namespace, so this will affect later code. It's basically `#define true false`. When I consider a library I will do a quick sniff test to look for very obvious mistakes, at which point I won't look further. | | |
|
