Unknown type name 'uintptr_t' about openexr HOT 7 OPEN

If std::numeric_limits<intptr_t>::max() works, the equivalent value could be generated via

std::numeric_limits<intptr_t>::max() / 2

Are you able to test that?

Since the /4 makes the number positive it doesn't seem important that kMaxSize needs to be a uintptr_t.

from openexr.

@reumia, that's curious as it's far from the only use of uintptr_t, it's used in the OpenEXR and OpenEXRCore libraries, so I would expect the failure there first if it's not defined, is that not happening? Are we missing an include?

@peterhillman, could you possibly take a look at this? The code in question declares kMaxSize as uintptr_t then only uses it on the following line where it's cast to streampos. Wouldn't it be better to simply declare it as streampos in the first place? And I'm not sure what edge case the uintptr_t(-1) is intended to catch, can that be simplified?

from openexr.

I think @kdt3rd wrote that bit. It certainly looks cleverer than anything I'd write. I would have been tempted to put a constant in there for the maximum file size that will be loaded into memory. I think declaring it as streampos isn't equivalent: a processor could have a 32 bit memory pointer size but still support 64 bit file pointers.

from openexr.

Thanks for the answers all, this got me into looking a bit closer at the issue and while I don't understand everything yet, I believe this might be partly an issue coming from OpenColorIO, here are some more information:

• We use OPENEXR_INSTALL_TOOLS instead of the correct OPENEXR_BUILD_TOOLS=OFF so in theory should not even build the tools and would not have seen any issues,
• OpenColorIO platform latest nightly build try to use C++20, this might not even be supported / tested by OpenEXR (goal of this workflow is to find issues early though)
• OpenColorIO still installs an "old" version of OpenEXR for this CI workflow, 3.1.5 by default (Apr. 2022)
• Looking at the compilation log, OpenEXRCore compile flags do not include any -std=c++20 or -std=gnu++20, rest of the libraries (Iex, IlmThread) and tools do which probably trigger the error here (as @cary-ilm rightfully pointed out, OpenEXRCore use that type in a few places already). I don't know exactly why OpenEXRCore doesn't get the C++ standard flag but suspect this is related to it's dependency with Imath, will have to dig further to understand.

from openexr.

Following up on this, did this get resolved?

And @remia, in case it matters, the reason that OpenEXRCore doesn't get the C++ standard flag is that it's written in C, not C++.

from openexr.