From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Kyungsik Lee <kyungsik.lee@lge.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Yann Collet <yann.collet.73@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
hyojun.im@lge.com, chan.jeong@lge.com
Subject: Re: [PATCH] LZ4: compression/decompression signedness mismatch
Date: Fri, 19 Jul 2013 12:04:46 +0300 [thread overview]
Message-ID: <20130719090445.GA2275@swordfish> (raw)
In-Reply-To: <20130719082710.GA11597@hulk>
On (07/19/13 17:27), Kyungsik Lee wrote:
> > >> On (07/12/13 11:28), Yann Collet wrote:
> > >> > The reference implementation, hosted at :�
> > >> > [1]https://code.google.com/p/lz4/
> > >> > only proposes char* (signed) types as part of the interface contract.
> > >> > I would recommend to keep it that way, to remain consistent.
> > >> > Regards
> > >>
> > >> Crypto lz4 accepts u8 * for both compression and decompression:
> > >>
> > >> lz4_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
> > >> unsigned int slen, u8 *dst, unsigned int *dlen)
> > >>
> > >> lz4_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
> > >> unsigned int slen, u8 *dst, unsigned int *dlen)
> > >>
> > >>
> > >> Internally LZ4 may cast unsigned char* to signed char*, the same way you
> > >> already do with compression:
> > >>
> > >> int lz4_compress(const unsigned char *src, size_t src_len,
> > >> unsigned char *dst, size_t *dst_len, void *wrkmem)
> > >>
> > >> calls:
> > >> lz4_compressctx(void *ctx,
> > >> const char *source, char *dest,
> > >> int isize, int maxoutputsize)
> > >>
> > >
> > >
> > > + lib/decompress_unlz4.c
> > > STATIC int INIT decompress(unsigned char *buf, int in_len,
> > > int(*fill)(void*, unsigned int),
> > > int(*flush)(void*, unsigned int),
> > > unsigned char *output,
> > > int *posp,
> > > void(*error)(char *x)
> > >
> > >>
> > >> At the moment API is a bit misaligned: unsiged char* for compression and signed char* for
> > >> decompression.
> > >>
> > >>
> > >> My 'real word' use case is, suppose:
> > >>
> > >> struct foo {
> > >> [..]
> > >> int (*compress)(const unsigned char *src, size_t src_len,
> > >> unsigned char *dst, size_t *dst_len, void *wrkmem);
> > >> int (*decompress)(const unsigned char *src, size_t src_len,
> > >> unsigned char *dst, size_t *dst_len);
> > >> };
> > >>
> > >>
> > >> and (for example) module also provides sysfs attribute, so user can switch select
> > >> LZO or LZ4 compressions depending of his needs:
> > >>
> > >> ->compress = lzo1x_1_compress;
> > >> ->decompress = lzo1x_decompress_safe;
> > >>
> > >> to
> > >> ->compress = lz4_compress;
> > >> ->decompress = lz4_decompress_unknownoutputsize;
> > >>
> > >>
> > >> the last one produces unneccessary compilation warning.
> > >>
> > >
> > > did you guys have a chance to review the patch? it does not change
> > > implementation/internals, just decompression exported symbols.
> >
> > IMHO, all these memory buffers should be of type "(const) void *", cfr.
> > e.g. read(2) and memcpy(3).
> >
> > This avoids casts in the callers.
>
> How about using "const unsigned char *" for the exported symbols in the
> patch?
will resend shortly.
> It is OK unless the patch changes the internal implementation.
>
it doesn't.
thanks,
-ss
next prev parent reply other threads:[~2013-07-19 9:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 9:24 [PATCH] LZ4: compression/decompression signedness mismatch Sergey Senozhatsky
[not found] ` <CADv+DGka4s1xc2UYqu+-EqHW8jA56JrtEE_sMsMOpc6NDmc6Zw@mail.gmail.com>
2013-07-12 9:48 ` Sergey Senozhatsky
2013-07-18 21:18 ` Sergey Senozhatsky
2013-07-18 21:29 ` Geert Uytterhoeven
2013-07-19 8:27 ` Kyungsik Lee
2013-07-19 9:04 ` Sergey Senozhatsky [this message]
2013-07-19 9:08 ` [PATCH] LZ4: compression/decompression signedness mismatch (v2) Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130719090445.GA2275@swordfish \
--to=sergey.senozhatsky@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chan.jeong@lge.com \
--cc=geert@linux-m68k.org \
--cc=hyojun.im@lge.com \
--cc=kyungsik.lee@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=yann.collet.73@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox