Consider requiring scratch memory to already be zeroed about lzfse

[ebainville]

Zeroing a block of memory is usually very fast. Requiring the memory to be 0 is changing the API contract.

Most users will actually call the encode function with scratch_buffer=NULL.

Users calling it with non NULL probably want to avoid re-allocating it for multiple calls. In that case, someone has to clear the buffer before each call anyway, and it will be done inside the LZFSE library.

[nemequ]

Zeroing a block of memory is usually very fast.

True, but calloc is often faster since the OS or libc may have a block of already zeroed memory sitting around. AFAIK it's pretty common for operating systems to keep some blobs of zeroed memory around just waiting for a calloc().

Requiring the memory to be 0 is changing the API contract.

Since the library isn't installed, I'm not sure how much benefit there is to committing to an API/ABI. IMHO it would be better to flesh out issues, then commit to an API/ABI. However, if you want to commit to the API right now I understand.

If that's the case, though, you should probably be installing the header and shared library (and preferably a pkg-config file). Should I put together a PR for that?

Most users will actually call the encode function with scratch_buffer=NULL.

Perhaps I'm missing something, but does the existing code actually work with NULL for the scratch buffer? I don't see any mallocs or callocs in lzfse, except for in lzfse_main.c… If I pass NULL to lzfse_encode_buffer in the Squash plugin it crashes.

If nothing else, I guess that is a pretty strong indicator that people aren't passing NULL there.

Users calling it with non NULL probably want to avoid re-allocating it for multiple calls. In that case, someone has to clear the buffer before each call anyway, and it will be done inside the LZFSE library.

Maybe, but that can get complicated pretty quickly in a multi-threaded application. You would need a pool of memory, which is basically what malloc/calloc provides (except it's probably better-optimized than whatever some random programmer will come up with).

[ebainville]

I'd prefer the LZFSE API to match the Compression API we have been shipping in macOS and iOS since last year. It doesn't require the scratch_buffer to be zeroed, and allows NULL.

Actually the lzfse.h header here documents the NULL case as valid, but you are right: there is no code handling this case. I'll need to fix this ASAP.

[nemequ]

I see you filed #28, so I may as well close this.