Comments (6)
Hi,
I looked at the liblzf source code, but I'm unable to find anything
NetBSD-specific there. Can you point me to more information about this?
Original comment by [email protected]
on 29 Mar 2011 at 8:33
from snappy.
Note the extra param at end of call to lzf_compress. NetBSD takes a pointer to
a hash that is optionally used (for low memory conditions). It appears macro
LZF_STATE_ARG determines if this hash is used. I need to dig into this more to
come to fully understand it, but didn't want to wait raising this issue here.
Look forward to hearing about your observations.
-bch
Original comment by [email protected]
on 29 Mar 2011 at 6:52
from snappy.
Again, where is your liblzf from? liblzf upstream has
unsigned int
lzf_compress (const void *const in_data, unsigned int in_len,
void *out_data, unsigned int out_len);
No fifth parameter, not even in an #ifdef.
If something in NetBSD (NetBSD ports?) has chosen to break liblzf's API, I'm
not entirely sure if Snappy upstream should follow suit, especially since one
might want to use the upstream version instead. At the very least, there should
be some sort of #define saying that a modified API is in use.
Original comment by [email protected]
on 29 Mar 2011 at 6:57
from snappy.
lzf I'm talking about ships w/ NetBSD system.
kamloops$ uname -srm
NetBSD 5.99.48 amd64
kamloops$ head -n 81 /usr/include/lzf.h |tail -n 30
/*
* Compress in_len bytes stored at the memory block starting at
* in_data and write the result to out_data, up to a maximum length
* of out_len bytes.
*
* If the output buffer is not large enough or any error occurs return 0,
* otherwise return the number of bytes used, which might be considerably
* more than in_len (but less than 104% of the original size), so it
* makes sense to always use out_len == in_len - 1), to ensure _some_
* compression, and store the data uncompressed otherwise (with a flag, of
* course.
*
* lzf_compress might use different algorithms on different systems and
* even different runs, thus might result in different compressed strings
* depending on the phase of the moon or similar factors. However, all
* these strings are architecture-independent and will result in the
* original data when decompressed using lzf_decompress.
*
* The buffers must not be overlapping.
*
* If the option LZF_STATE_ARG is enabled, an extra argument must be
* supplied which is not reflected in this header file. Refer to lzfP.h
* and lzf_c.c.
*
*/
unsigned int
lzf_compress (const void *const in_data, unsigned int in_len,
void *out_data, unsigned int out_len,
LZF_STATE htab);
Original comment by [email protected]
on 29 Mar 2011 at 8:22
from snappy.
I talked to the liblzf author. Quote (some spelling mistakes fixed and
punctuation added): “liblzf doesn't have this parameter. NetBSD has had to
patch their copy; you can enable it when embedding liblzf. [...] I don't think
Snappy should support that. [...] I think breaking the API for the default
system-provided liblzf is just broken.”
So, end conclusion: If NetBSD wants to break the liblzf API and still expose it
to userspace, they will also need to patch any callers to it. Either that, or
you can just compile Snappy against unmodified upstream liblzf. In other words,
I'm going to reject this bug as invalid.
Original comment by [email protected]
on 29 Mar 2011 at 11:10
- Changed state: Invalid
from snappy.
I'll discuss w/ NetBSD folks. Thanks for your attention.
-bch
Original comment by [email protected]
on 30 Mar 2011 at 1:06
from snappy.
Related Issues (20)
- Various MSVC x64 compiler size_t warnings (C4267) HOT 6
- Does not handle data larger than 4GB HOT 8
- Mistakes on the start page HOT 5
- cppcheck - Member variable is not initialized in the constructor. HOT 2
- Type 'ssize_t' not defined for MSVC builds HOT 4
- snappy needs a command line utility HOT 5
- MIsspelled in code HOT 1
- testdata/mapreduce-osd-1-pdf contains "DO NOT DISTRIBUTE" disclaimer HOT 3
- Patch for compiling Snappy with MSVC on Windows HOT 3
- Bug in IncrementalCopyFastPath HOT 6
- use ctypes.util.find_library HOT 3
- ARMv6 and unaligned access HOT 3
- Decompression issues with Snappy 1.1.2 HOT 3
- ahsan ullah HOT 2
- Seeing Null Values from Hive with Snappy Compression HOT 1
- No versioned link for current build HOT 2
- ppc64le entry is needed in config.guess file HOT 4
- performance issue in snappy.cc - I am using version 1.1.2 HOT 2
- Unnecessary memory allocation in snappy.cc:Compress HOT 1
- bad_alloc exception not caught in snappy.cc::Compress
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from snappy.