roestvrijstaal/crcutil

Automatically exported from code.google.com/p/crcutil

crcutil's Issues

cksum-compatible CRC?

Hello,

I have been trying to adapt crcutil as a high-performance, 
concatenation-capable cksum replacement. However, I notice that the crc32 
generating polynomial used in crcutil is the "reverse form" polynomial, 
0xEDB88320 (per Wikipedia terminology), not the "normal" form (0x04C11DB7) 
commonly used. And while the CRC outputs from crcutil match those from BSD 
"cksum -o 3", when I replace the generating polynomial with 0x04C11DB7 the 
outputs don't match those from "cksum".

Any advice on what I'm doing wrong?

Thanks,
-ak

Original issue reported on code.google.com by [email protected] on 14 Dec 2012 at 4:30

minor flaw: inconsistent check syntax for preprocessor defines

What steps will reproduce the problem?
1. Look at the code, e.g.
2. https://code.google.com/p/crcutil/source/browse/code/platform.h#40 and
3. https://code.google.com/p/crcutil/source/browse/code/platform.h#49

At time defined(PREDEFINE) is used, at time it isn't

Original issue reported on code.google.com by [email protected] on 25 Feb 2014 at 11:46

FTBFS on amd64

Crcutil FTBFS on amd64 as follows:

/bin/bash ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-D_FORTIFY_SOURCE=2 -DCRCUTIL_USE_MM_CRC32=1 -Wall -msse2 -Icode -g -O2 -fPIE
-fstack-protector-strong -Wformat -Werror=format-security -c -o
code/crc32c_sse4.lo code/crc32c_sse4.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2
-DCRCUTIL_USE_MM_CRC32=1 -Wall -msse2 -Icode -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -c code/crc32c_sse4.cc -fPIC -DPIC -o
code/.libs/crc32c_sse4.o
In file included from code/crc32c_sse4.h:23:0,
from code/crc32c_sse4.cc:19:
code/crc32c_sse4_intrin.h: In function 'unsigned int _mm_crc32_u8(unsigned int,
unsigned char)':
code/crc32c_sse4_intrin.h:56:41: error: '__builtin_ia32_crc32qi' was not
declared in this scope
return __builtin_ia32_crc32qi(__C, __V);
^
code/crc32c_sse4_intrin.h: In function 'long long unsigned int
_mm_crc32_u64(long long unsigned int, long long unsigned int)':
code/crc32c_sse4_intrin.h:62:41: error: '__builtin_ia32_crc32di' was not
declared in this scope
return __builtin_ia32_crc32di(__C, __V);
^
code/crc32c_sse4_intrin.h:63:1: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
code/crc32c_sse4_intrin.h: In function 'unsigned int _mm_crc32_u8(unsigned int,
unsigned char)':
code/crc32c_sse4_intrin.h:57:1: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
Makefile:685: recipe for target 'code/crc32c_sse4.lo' failed

The remedy is to add "-mcrc32" to CFLAGS (as mentioned in README).
It would be nice to fix this by adding corresponding autotools checks (to 
detect available platform features) or using this build flag by default (if 
appropriate).

Original issue reported on code.google.com by [email protected] on 7 Dec 2014 at 12:59

FTBFS@i686 (1/2): "PIC register clobbered by '%ebx' in 'asm'" :: please use <cpuid.h>

On i686 compilation fails as follows:

libtool: compile: g++ -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2 -mcrc32 -msse2 -DCRCUTIL_USE_ASM=0 -DCRCUTIL_USE_MM_CRC32=1 -Wall -msse2 -Icode -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c code/multiword_128_64_gcc_amd64_sse2.cc -fPIE -o code/multiword_128_64_gcc_amd64_sse2.o >/dev/null 2>&1
code/crc32c_sse4.cc: In static member function 'static bool crcutil::Crc32cSSE4::IsSSE42Available()':
code/crc32c_sse4.cc:331:4: error: PIC register clobbered by '%ebx' in 'asm'
);
^
Makefile:685: recipe for target 'code/crc32c_sse4.lo' failed

It seems to be because someone neglected to use "#include <cpuid.h>" as 
commented in "code/crc32c_sse4.cc":

> // Not using "cpuid.h" intentionally: it is missing from too many 
installations.

However "cpuid.h" is part of GCC since 4.4 (or earlier) hence it should be 
universally available. Please consider using "cpuid.h" instead of custom 
workaround(s) to avoid that kind of problems.
I prepared the attached patch that seems to fix the problem (tests are passing) 
but I'm far from being confident in inline asm so my patch needs review from 
someone who really understands how it should work.

Original issue reported on code.google.com by [email protected] on 8 Dec 2014 at 4:24

Attachments:

• unclobber.patch

build proper library

LizardFS project uses "crcutil" so perhaps it's time to turn the latter to 
proper library. Please review the attached patch.
Thanks.

Original issue reported on code.google.com by [email protected] on 7 Dec 2014 at 12:51

Attachments:

• library.patch

FTBFS@i686 (2/2): 'asm' operand has impossible constraints

Yet another FTBFS on i686:

code/multiword_64_64_gcc_i386_mmx.cc: In member function 'crcutil::GenericCrc<_Crc, _TableEntry, _Word, kStride>::Crc crcutil::GenericCrc<_Crc, _TableEntry, _Word, kStride>::CrcMultiwordI386Mmx(const void*, size_t, const Crc&) const [with _Crc = long long unsigned int; _TableEntry = long long unsigned int; _Word = long long unsigned int; int kStride = 4; crcutil::GenericCrc<_Crc, _TableEntry, _Word, kStride>::Crc = long long unsigned int; size_t = unsigned int]':
code/multiword_64_64_gcc_i386_mmx.cc:252:37: error: 'asm' operand has impossible constraints
[table_word] "m" (table_word));
^
Makefile:685: recipe for target 'code/multiword_64_64_gcc_i386_mmx.lo' failed

I've managed to "fix" it by adding "-DCRCUTIL_USE_ASM=0" to CPPFLAGS but there 
should be a better way...

Original issue reported on code.google.com by [email protected] on 8 Dec 2014 at 4:27

tests FTBFS on non-x86

Please review the attached patch to fix tests compilation on non-x86.

Original issue reported on code.google.com by [email protected] on 27 Feb 2015 at 7:47

Attachments:

• build-fix-tests.patch

modernise configure.ac

Please consider updating "configure.ac" using attached patch to avoid ugly 
build-time warnings with current automake. Thanks.

Original issue reported on code.google.com by [email protected] on 7 Dec 2014 at 12:48

Attachments:

• automake.patch

not supported on big-endian architectures?

crcutil seems to be worthless on big-endian architectures.
The attached patch introduces endianness check to "configure" and aborts build 
if big-endian arch. is detected.

Original issue reported on code.google.com by [email protected] on 27 Feb 2015 at 7:51

Attachments:

• build-abort-be.patch

detect "-mcrc32" availability

Unconditional build with "-mcrc32" fails when it is not available (e.g. on 
non-x86 architectures etc.).
The attached patch detects "-mcrc32" and uses it when possible.

Original issue reported on code.google.com by [email protected] on 27 Feb 2015 at 7:24

Attachments:

• detect-mcrc32.patch