Namespace the bitstream API?

[rtobar]

Hi,

While working today with a 4- or 5-layered piece of software, I ran into an issue where the application ended up loading stream_open (the bitstream opening API from zfp) from a different, unrelated library that exported the same symbol.

I'm starting a conversation on that other place too, where renaming that symbol seems like an easy task (it seems to be used internally only, and not part of the public API). I wanted to reach on this repo too to see whether there would be some appetite to rename the stream_* APIs so that they are better namespaced, making them e.g. zfp_bitstream_* instead.

I found that the rest of the high- and low-level C APIs are all prefixed with zfp_, so doing this would also better align all definitions.

I understand this is an obvious, breaking change, so it'd take a while until a new major, breaking release is planned.

Thanks for your attetion!

[rtobar]

For reference, I opened a PR against the other library I mentioned under HEASARC/cfitsio#98. In their case (from what I can tell, I might be wrong) the stream_* functions are internal, so renaming them shouldn't be controversial.

[lindstro]

This is a reasonable suggestion, but the decision not to prefix the bitstream API with zfp is deliberate. Long term, we plan to completely separate the bitstream library, as it has uses beyond zfp. We also plan to provide C++ and CUDA/HIP APIs.

Of course, such a separation alone does not address the issue you're running into. It would make sense to use something akin to the configurable C namespace we're using for cfp, though as a prefix and not a struct:
https://github.com/LLNL/zfp/blob/b9442d10e4c035c447e094767b50fda958a1319e/include/zfp/array.h#L26-L30

Another solution would be to leave the bitstream library internal only, with static functions in a header. That's how the library is used internally in zfp, but we also expose the same functions externally as users must call functions like stream_open with zfp. That does not mean that we could not keep the bitstream library header-only, but there might be other implications such as interoperability with Python and Fortran that would have to be resolved.

Thanks for getting this on our radar. We will think about how to best resolve this issue for the next zfp release.