Peter Lindstrom

I was commenting on undefined behavior in the context of "all nontrivial C programs contain undefined behavior." :-) C90 and C99 (which are the standards zfp targets) allow signed integer...

> What I tried to say before is, I do not think you can overflow when Fortran passes `INTEGER(kind=c_size_t)` to a `ptrdiff_t` because there is no way for Fortran to...

The logic [here](https://github.com/LLNL/zfp/blob/35155961eca5bce0714c7ed0eb0e3735ae0f3045/CMakeLists.txt#L258) and [here](https://github.com/LLNL/zfp/blob/35155961eca5bce0714c7ed0eb0e3735ae0f3045/utils/CMakeLists.txt#L9) should take care of this. Your CMake log indicates that `HAVE_MATH` is set, i.e., your compiler should not need `-lm`. Perhaps something got outdated in...

@felixonmars Wow--thanks for finding the issue. It's odd that 0.5.5 would build and 1.0.0 wouldn't when they use the same `HAVE_MATH` logic. I'm not sure `volatile` would solve the problem...

Thanks for verifying. We'll add a fix on `develop`.

I wonder if this issue is related to CUDA bug #121, which was recently fixed. Although I would not expect this to result in a segmentation fault. I first need...

No immediate plans, but it would be straightforward to extend fpzip to support half precision. The one gotcha is the lack of language support, though __fp16 could be conditionally enabled...

This would be rather easy to support since one of the first steps in fpzip is to convert floating-point values to integers. But there already exist numerous lossless compressors for...

Sorry for a late response--somehow I didn't see your follow-up. One simple idea you might try is to just cast your unsigned integer data to floats and fpzip compress them...

@william-silversmith Thanks for this contribution. Let us look it over. @da-wad Can you please provide some input?