Re: [HACKERS] Custom compression methods

On Mon, Mar 01, 2021 at 08:53:09PM +0530, Dilip Kumar wrote:
> On Mon, Mar 1, 2021 at 5:36 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > On Mon, Mar 1, 2021 at 11:06 AM Justin Pryzby <pryzby(at)telsasoft(dot)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