> > On Tue, Mar 27, 2018 at 10:35:29PM +0800, Xiao Guangrong wrote: > >> > > No, we can't make the assumption that "error _must_ be caused by page >> > > update". >> > > No document/ABI about compress/decompress promised it. :) > > Indeed, I found no good documents about below errors that jiang.biao > pointed out. Hi, Peter The description about the errors comes from here, http://www.zlib.net/manual.html And about the error codes returned by inflate(), they are described as， ** inflate() returns Z_OK if some progress has been made (more input processed or more output produced), Z_STREAM_END if the end of the compressed data has been reached and all uncompressed output has been produced, Z_NEED_DICT if a preset dictionary is needed at this point, Z_DATA_ERROR if the input data was corrupted (input stream not conforming to the zlib format or incorrect check value, in which case strm->msg points to a string with a more specific error), Z_STREAM_ERROR if the stream structure was inconsistent (for example next_in or next_out was Z_NULL, or the state was inadvertently written over by the application), Z_MEM_ERROR if there was not enough memory, Z_BUF_ERROR if no progress was possible or if there was not enough room in the output buffer when Z_FINISH is used. ... ** According to the above description, the error caused by page update looks more like tend to return Z_DATA_ERROR, but I do not have env to verify that. :) As I understand it, the real compress/decompress error cases other than that caused by page update should be rare, maybe the error code is enough to distinguish those if we can verify the the error codes returned by page update and other silent failures by test. If so, we can cut the cost of memcpy. If not, I agree with Guangrong's idea too. I never read the zlib code and all my information comes from the manual, so if anything inaccurate, pls ignore my option. :)
Regards, Jiang
