xiaolu / lz4

Automatically exported from code.google.com/p/lz4
1 stars 1 forks source link

LZ4_compressBound symbol isn't in the shared library #113

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This symbol is defined as 'inline', so it didn't get to the library.

Once there is a shared library, all symbols with your prefix (LZ4_) should be 
defined there. People who want this inlined can still use LZ4_COMPRESSBOUND 
macro.

With shared library, it should be possible to do all operations without the 
need to include headers. libgzip, liblzo2, etc are like this.

Original issue reported on code.google.com by yuriv...@gmail.com on 6 Feb 2014 at 11:01

GoogleCodeExporter commented 9 years ago
LZ4_uncompress is also missing

Original comment by yuriv...@gmail.com on 6 Feb 2014 at 11:45

GoogleCodeExporter commented 9 years ago
ok.

> With shared library, it should be possible to do all operations without the 
need to include headers.

Just for my information, I'm surprised a compilation using LZ4 compression 
function wouldn't require a *.h. Prototype must be defined somewhere.
This prototype definition is a requirement, why not using lz4.h for this ?

Original comment by yann.col...@gmail.com on 7 Feb 2014 at 1:37

GoogleCodeExporter commented 9 years ago
You shouldn't assume that the calling code is always C/C++. There are other 
languages around, including proprietary ones.

One standard way to bind to the C-library is to always have C layer with .h 
files, etc.

However, if the interface is very simple, one can just load the library and use 
the symbols (dlopen/dlsym). dlsym gets symbol by name. And if all logic is in 
the shared library and the interface is simple, it can just call it. It can 
provide buffers, sizes, etc. But when you have significant logic in .h, this 
pretty much cuts down such simple users, and forces everybody to have a C 
binding layer.

Now, interface-wise, lz4 doesn't have to be complex at all. So the fact that 
LZ4_compressBound and LZ4_uncompress are in .h just unnecessarily 
overcomplicates interface, hurting some potential users binding to it. It 
forces everybody to have C layer, when there is really no need for it.

You can take zlib.h (from http://www.zlib.net) as a reference. The header 
strictly defines the interface without any inline functions or complex macros.

Original comment by yuriv...@gmail.com on 7 Feb 2014 at 8:52

GoogleCodeExporter commented 9 years ago
The following package
is a wip r114
which attempts to implement the requested changes.

Original comment by yann.col...@gmail.com on 27 Feb 2014 at 11:05

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by yann.col...@gmail.com on 27 Feb 2014 at 11:05

GoogleCodeExporter commented 9 years ago
Fixed into r114

Original comment by yann.col...@gmail.com on 12 Mar 2014 at 2:57