Menu
▾
▴
#433 irrTypes __WORDSIZE bug
irrTypes.h uses __WORDSIZE identifier internally to use it in u64 type definition. However, this identifier is defined only if <stdint> is included (at least on BSD-like systems, including OSX). I. e. in cases when irrTypes.h is included by client code after <stdint> and before <stdint> this leads to different functions signatures and client code may fail with "undefined symbol" on linking stage.</stdint></stdint></stdint>
Like here: https://github.com/minetest/minetest/issues/1687#issuecomment-61368769
Maybe irrTypes.h should be more cross-platform and shouldn't use __WORDSIZE identifier? Or at least should try to do everything to make sure __WORDSIZE was defined previously (i. e. include <stdint> on BSD-like systems).</stdint>
The reason it's using strange stuff like WORDSIZE etc was an attempt to get it cross-platform (we started out with "uint64_t" and "unsigned __int64" until first protests came in).
Just including stdint also won't work because it does not exist on some systems. So we have to figure out first exactly which systems this will work and on which it won't work.
This kind of stuff is the reason so may libs use specific headers which are created by script before compiling. Because you can't do checks like - does this #include file exist inside c++. Irrlicht tries to avoid those kind of scripts, but it's getting tricky in such a case.
I couldn't find a good solution so far - ideas still welcome.
First try to fix this in svn trunk r5480. But I will need to test this some more, if no problems are reported I might backport it to Irrlicht 1.8 before releasing another version for that one.
Next try to fix this in r5489. Previous fix was a failure. I basically see no way to include stdint.h in a safe way which is not completely horrible. Basically stdint.h doesn't exist in c++ because it's C99 - and the fact that it does exist often won't make it better. Using stdint instead is also not completely trivial as it introduces then namespaces. And also that causes then problems with c-code. And Irrlicht compiles c/c++ code mixed (and can be used from both).
So my workaround this time is to include limits.h as that uses WORDSIZE.
No guarantee this fixes the problem...
But on another note - your include order should always be: First project includes, then library includes and last system includes. So if this bug doesn't happen when you do that then it's not really a problem anyway I think.
No more complains from OSX users for last years, so without further info I suppose the fix worked and I'm closing this.
Another fix in r6278 thanks to report from edo9300 here: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=7&t=52795
In r6504 this got back-ported to Irrlicht 1.8 branch (will be in 1.8.6)