From: Kyungsik Lee <kyungsik.lee@lge.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.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 17:27:10 +0900 [thread overview]
Message-ID: <20130719082710.GA11597@hulk> (raw)
In-Reply-To: <CAMuHMdXCsRKpFQRwMTteQpBCbtuJVqmb9UvszHi3ffTS=RxJmw@mail.gmail.com>
On Thu, Jul 18, 2013 at 11:29:57PM +0200, Geert Uytterhoeven wrote:
> On Thu, Jul 18, 2013 at 11:18 PM, Sergey Senozhatsky
> <sergey.senozhatsky@gmail.com> wrote:
> > On (07/12/13 12:48), Sergey Senozhatsky 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?
It is OK unless the patch changes the internal implementation.
Thanks,
Kyungsik
next prev parent reply other threads:[~2013-07-19 8:27 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 [this message]
2013-07-19 9:04 ` Sergey Senozhatsky
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=20130719082710.GA11597@hulk \
--to=kyungsik.lee@lge.com \
--cc=akpm@linux-foundation.org \
--cc=chan.jeong@lge.com \
--cc=geert@linux-m68k.org \
--cc=hyojun.im@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sergey.senozhatsky@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.