On Mon, Mar 1, 2021 at 11:06 AM Justin Pryzby <pry...@telsasoft.com> wrote:
> Thanks. It seems like that explains it. > I think if that's a problem with recent versions, then you'll have to > conditionally disable slicing. > https://packages.debian.org/liblz4-dev > > Slicing isn't generally usable if it sometimes makes people's data > inaccessible > and gives errors about corruption. > > I guess you could make it a compile time test on these constants (I don't know > the necessary version, though) > > #define LZ4_VERSION_MAJOR 1 /* for breaking interface changes */ > #define LZ4_VERSION_MINOR 7 /* for new (non-breaking) interface > capabilities */ > #define LZ4_VERSION_RELEASE 1 /* for tweaks, bug-fixes, or development */ > #define LZ4_VERSION_NUMBER (LZ4_VERSION_MAJOR *100*100 + LZ4_VERSION_MINOR > *100 + LZ4_VERSION_RELEASE) > > If the version is too low, either make it #error, or disable slicing. > The OS usual library version infrastructure will make sure the runtime version > is at least the MAJOR+MINOR of the compile time version. I think we can check the version and if it too low i.e. below1.8.3 ( in this release the slicing issue was fixed) then we can call the full decompression routine from the slicing function. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
