On Mon, Mar 01, 2021 at 08:53:09PM +0530, Dilip Kumar wrote:
> On Mon, Mar 1, 2021 at 5:36 PM Dilip Kumar <dilipbal...@gmail.com> wrote:
> > 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.
Thank you
+#elif LZ4_VERSION_NUMBER < 10803
+ return lz4_cmdecompress(value);
+#else
It occurred to me that this should actually compare the runtime version with
LZ4_versionNumber(). That way, a library upgrade can enable the slice
behavior.
--
Justin
