lixo6500
commented
7 years ago I would like to reinforce the urgency of the above mentioned APIs, now that I looked at the insides of "flif_encoder_encode_memory"
The function documentation does not tell much about the buffers it expects. Since there is no way to know the size of the encoded data, one would assume that the API expects just a pointer and it will take care of allocating memory. So far so good.
The problems:
- the API does not tell that the user is responsible for the buffer
- the API does not tell how the user is supposed to free the buffer
- being a C API, one would reasonably expect to use free() to release the memory, but the API is using C++ new/delete on the provided buffer.
All those problems would be solved by some sort of stream API.
Also, maybe this kind of undefined behavior regarding the (probable) use of free with memory allocated with new[] may be the cause of the problems mentioned by that other issue "Google" opened.
OronDF343
Both the encoder and decoder APIs need some sort of stream interface.
On the decoder side, things are almost ready. The decoding already using a stream interface internally (BlobReader). All that is remaining to do is to provide some sort of struct the user can fill with function pointers to read data and seek.
The encoder also needs the same. Allow the user to provide function pointers to write and seek.
It could be something as simple as
// reads at most "size" bytes into buffer. Return the number of read bytes uint32_t read_data(void userData, void buffer, uint32_t size);
// seeks the stream to the requested position. Return true if successfull bool seek_data(void* userData, uint32_t position);
// writes at most "size" bytes from buffer. Return the number of written bytes uint32_t write_data(void userData, const void buffer, uint32_t size);