Can `ZSTD_getFrameHeader()` function be moved to stable API?

[animalize]

If the frame header will not be changed in the future, maybe ZSTD_getFrameHeader() function can be moved to stable API.

[Cyan4973]

The frame header itself, as an IETF RFC defined binary format, is indeed pretty stable and likely to remain this way for the foreseeable future.

That being said, the difficulty with ZSTD_getFrameHeader() is that it depends on the definition of structure ZSTD_frameHeader , which would have to become stable too. Now, even if the binary format doesn't change, the structure itself could change to support new functionalities. For example, last time we modified it, I think it was to return blockSizeMax in v1.3.2 (an information which could also be derived indirectly, showing that there are many ways to achieve the same result).

Depending on a structure definition is something we try to avoid (in general) for the stable public API, because structures are extremely rigid and can't be changed afterwards. That being said, if we are confident that the current structure is useful enough and is unlikely to change in the future, that would make it a potential candidate into stable API.

[terrelln]

One potential change we want to reserve the right to make is to prescribe meaning to the reserved bits in the zstd header. In which case the ZSTD_frameHeader structure would probably need to be changed to expose that.

[felixhandte]

If we cared to, we could consider adding an int _reserved field to the struct definition and stabilizing with that.

[ghost]

If we cared to, we could consider adding an int _reserved field to the struct definition and stabilizing with that.

Sounds good. If the format will be changed greatly in the future, can add a ZSTD_getFrameHeaderV2() function.

ZSTD_getFrameHeader() function is convenient to get information from a frame header. (I want to use it to detect skippable frame.)

[terrelln]

Yes, it is planned now. Closing in favor of #3390.