32-bit build fails due to out-of-range size_t literals #87

Activity

1. saki7

   added

   bugSomething isn't workingSomething isn't working

   CIBuild system issuesBuild system issues

   need more infoRequires additional info from the reporterRequires additional info from the reporter

   on Sep 15, 2026
2. saki7 commented on Sep 15, 2026

   

   saki7

   on Sep 15, 2026

   Member

   More actions

   Fixing this specific issue is straightforward, but we do not currently support 32-bit platforms. The sizeof(std::size_t) handling was some optimistic code I wrote without being particularly confident that it would actually work correctly on 32-bit systems.

   That said, I think supporting 32-bit platforms is worth considering. The main problem is that I do not currently have a working 32-bit environment on my local machine, so I would not be able to debug day-to-day development on 32-bit systems, not just the changes related to this particular issue.

   However, if we decide to support 32-bit platforms, I think we should first add 32-bit CI coverage. Otherwise, in practice, nobody is likely to use Iris for 32-bit projects, because Iris simply does not support 32-bit builds by default.

   So I would like to ask a couple of questions:

   • Do you actually have any plans to use Iris in a 32-bit project?
   • How did you find this issue? Did you try to make all, or were you just browsing through the headers?
3. Raclamusi commented on Sep 15, 2026

   

   Raclamusi

   on Sep 15, 2026

   Author

   More actions

   Thanks for the clarification.

   I currently have no plans to use Iris in a 32-bit project. My interest is mainly technical.

   I found this while trying to build Iris for WebAssembly (wasm32) with Emscripten:

   emcmake cmake -S . -B build_wasm32 -G Ninja -DCMAKE_BUILD_TYPE=Release
   cmake --build build_wasm32
   
4. saki7 commented on Sep 15, 2026

   

   saki7

   on Sep 15, 2026

   Last edited by saki7

   Member

   More actions

   Thanks for the info. That actually helps a lot, because supporting 32-bit desktop/server/embedded environments and supporting WASM are quite different things, with the latter being technically more challenging.

   To be honest, supporting additional environment is not as simple as rewriting a few lines of code. We would need to permanently maintain a fully functional 32-bit CI workflow. If you have actual plans to use Iris in a real 32-bit product, I'm willing to spend some time fixing the relevant issues.
5. saki7

   removed

   need more infoRequires additional info from the reporterRequires additional info from the reporter

   on Sep 15, 2026
6. Raclamusi commented on Sep 15, 2026

   

   Raclamusi

   on Sep 15, 2026

   Author

   More actions

   I wasn't specifically asking for WebAssembly support. I simply used wasm32 as an example of a 32-bit environment (since I've been using Emscripten recently).

   The reason I opened this issue was that I found it odd that Iris has implementations selected based on sizeof(std::size_t), while also using size_t literals that exceed the 32-bit range.
   In particular, such code can be found in the definition of iris::hash_combine:

   template<class T>
   [[nodiscard]] constexpr std::size_t hash_combine(std::size_t const seed, T const& v) noexcept
   {
       return detail::hash_mix<sizeof(std::size_t)>(
           seed + 0x9e3779b97f4a7c55uz + iris::hash_value(v)
       );
   }

   If 32-bit support is not intended, I don't think that having size_t literals that exceed the 32-bit range is a problem. I mainly wanted to point out the apparent inconsistency.
7. saki7 commented on Sep 15, 2026

   

   saki7

   on Sep 15, 2026

   Member

   More actions

   Yes, I understand that the code you mentioned is incorrect in a 32-bit environment.

   My point is that if we are going to support a 32-bit environment, it will be some specific 32-bit architecture, not an hypothetical 32-bit machine. So if a user tries our library on WASM, that would effectively become the first concrete 32-bit target we would need to consider supporting.

   There is not much practical value in pointing out that a library does not work on a particular platform while also saying that we are not actually going to use or support that platform.

   If we are not targeting any specific 32-bit platform, then saying that the code does not work on an arbitrary 32-bit system does not lead to a particularly useful conclusion. The code may be incorrect in technical sense, but we are obviously not supporting such a platform yet.
8. Raclamusi commented on Sep 16, 2026

   

   Raclamusi

   on Sep 16, 2026

   Author

   More actions

   That makes sense. I understand your point.

   My report was more of a technical observation than a practical issue, so I agree that it doesn't have much value without a specific 32-bit target to support. Thanks for the explanation.