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

[Raclamusi]

This project appears to consider 32-bit environments, as iris/hash.hpp provides different implementations depending on sizeof(std::size_t).
However, some size_t literals (such as 0xe9846af9b1a615duz in iris/hash.hpp) exceed the 32-bit range.
On 32-bit targets, this causes compilation errors such as error: 'size_t' literal is out of range of possible 'size_t' values.

[saki7]

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?

[Raclamusi]

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

[saki7]

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.

[Raclamusi]

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.

[saki7]

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.

[Raclamusi]

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.