On Sun, Feb 23, 2025 at 01:02:41PM +0900, Sergey Senozhatsky wrote: > > if I understood it correctly. Which would make it: return 0 on success > or -ENOSPC otherwise. So if crypto API wants consistency and return -ENOSPC > for buffer overruns, then for lz4/lz4hc it also becomes binary: either 0 or > -ENOSCP. Current -EINVAL return looks better to me, both for deflate and > for lz4/lz4hc. -ENOSPC is an actionable error code, a user can double the > dst_out size and retry compression etc., while in reality it could be some > SW/HW issue that is misreported as -ENOSPC. When you're compressing you're trying to make it smaller. It's always better to not compress something rather than doubling the buffer on ENOSPC. In any case, no software compression algorithm should ever fail for a reason other than ENOSPC. Hardware offload devices can fail of course. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
