Tests pass with GL_CRC_SLICE_BY_8 set
On Wed, 16 Oct 2024 at 13:52, Simon Josefsson wrote:
> Sam Russell writes:
>
> >> People using the crc module who want to disable the faster/larger CRC32
> >> implementation can add 'gl_crc_slice_by_8=yes' to their configure.ac
> >> before invoking gnulib
Thanks, my mistake on the dropped CC
On Tue, 22 Oct 2024 at 22:24, Simon Josefsson wrote:
> Thanks, pushed in your name -- next time please attach git-format-patch
> output that includes the commit message, and keep cc to the list.
>
> /Simon
>
> Sam Russell writes:
>
> >> Why '__'? I think
Thanks, pushed in your name -- next time please attach git-format-patch
output that includes the commit message, and keep cc to the list.
/Simon
Sam Russell writes:
>> Why '__'? I think they should be dropped.
>
> thanks, bad habit, other codebases use them as they work better with
> standard
Michele Locati noticed that executing programs on Windows has an additional
complexity that does not exist on Unix: On Unix, programs have their runtime
path embedded in the executable ('-rpath' option). On Windows, this is not
the case; instead, DLLs used by the executable are looked up [1]
- in
Sam Russell writes:
> +__uint32_t trailing_unaligned_byte_hashes[32] = {
> +__uint32_t leading_unaligned_byte_hashes[32] = {
> +__uint32_t variable_alignment_variable_length_hashes[] = {
Why '__'? I think they should be dropped.
> main (int argc, char *argv[])
A detail, but if the variables
> I'd opt for reducing this set of expected values to 32 values,
> by reintroducing the memcpy() trick from your previous patch:
Attached is a patch with this implementation
On Tue, 22 Oct 2024 at 14:34, Sam Russell wrote:
> I think we are massively overengineering this. We shouldn't need to
>
I think we are massively overengineering this. We shouldn't need to
future-proof tests for changes that *might* be added in the future, and
having 32x32 hashes in a table at the start of the test is not a big deal
(it took less than a second to generate and it'll take the same amount of
time if we
Hi Simon,
> How about an aggregated trick, incrementally hashing each output crc value
> and at the end just compare the hash against an expected value? Instead of
> comparing each incremental crc value against a table.
While this needs fewer expected values, it makes debugging harder
in case o
How about an aggregated trick, incrementally hashing each output crc value and
at the end just compare the hash against an expected value? Instead of
comparing each incremental crc value against a table. This trick works better
for many polynomials too. The hash doesn’t have to be strong so cou
Sam Russell wrote:
> ran the tests just printing out the values from the current implementation
> and then put them into arrays that we now check against, the idea being
> that the current implementation is correct and we expect future
> implementations to match the current implementation
Yes, tha
> It would be better to use the randomb[] array as input
done
> Please put a space between a function-like identifier and an opening
> parenthesis (GNU Coding Style).
done
> sizeof(unsigned long int) = 8 does not reflect the maximum possible
> alignment. Already nowadays, for some things the al
Sam Russell wrote:
> is there anymore feedback on this?
+ char plaintext[] = "Gnulib crc testsGnulib crc tests"
+ "Gnulib crc testsGnulib crc tests"
+ "Gnulib crc testsGnulib crc tests"
+ "Gnulib crc testsGnulib crc tests"
+
12 matches
Mail list logo
