Is there a reason you chose to implement the CRC32 algorithm in a reversed order?

Everything from defining the polynomial to generating the lookup table to updating the CRC is reversed.

In build.rs IEEE is defined as 0xedb88320 which is the reflected form of the correct polynomial 0x04C11DB7. Then make_table_crc32() works in a Little Endian way.

I am currently using a custom polynomial and custom XOR value, and I cannot use your code in the current state. I have modified it to use the correct CRC32 algorithm. Are you interested in me making a pull request?

this adds support for no_std applications/libraries (like microcontrollers) by using conditional features

• rust-lang/cargo#633

On nightly with no_std:

#  rustup run nightly cargo test --features no_std                                                                                                                                           <<<
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target/debug/deps/crc-c3e90d0dfab413be

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/deps/crc-9d7b680262789a74

running 10 tests
test crc32::checksum_castagnoli ... ok
test crc32::checksum_ieee ... ok
test crc32::digest_castagnoli ... ok
test crc32::checksum_koopman ... ok
test crc32::digest_ieee ... ok
test crc64::checksum_ecma ... ok
test crc32::digest_koopman ... ok
test crc64::digest_iso ... ok
test crc64::checksum_iso ... ok
test crc64::digest_ecma ... ok

test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/deps/hash-bb44b103cb920ad0

running 2 tests
test hasher::checksum_hashcrc32 ... ok
test hasher::checksum_hashcrc64 ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured

   Doc-tests crc

running 2 tests
test src/lib.rs -  (line 6) ... ok
test src/lib.rs -  (line 27) ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured

on stable with std:

# rustup run stable cargo test                                                                                                                                                                 
   Compiling crc v1.4.0 (file:///home/garrett/projects/ruststuff/crc-rs)                                                                                                                                          
    Finished dev [unoptimized + debuginfo] target(s) in 1.64 secs                                                                                                                                                 
     Running target/debug/deps/crc-57a43f894e443797                                                                                                                                                               
                                                                                                                                                                                                                  
running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/deps/crc-79b2fcd023832a0c                                                                                                                                                               
                                                                                                                                                                                                                  
running 10 tests
test crc32::checksum_castagnoli ... ok                                                                                                                                                                            
test crc32::checksum_ieee ... ok                                                                                                                                                                                  
test crc32::checksum_koopman ... ok                                                                                                                                                                               
test crc32::digest_castagnoli ... ok                                                                                                                                                                              
test crc32::digest_ieee ... ok                                                                                                                                                                                    
test crc64::checksum_iso ... ok                                                                                                                                                                                   
test crc64::checksum_ecma ... ok                                                                                                                                                                                  
test crc64::digest_ecma ... ok                                                                                                                                                                                    
test crc32::digest_koopman ... ok                                                                                                                                                                                 
test crc64::digest_iso ... ok                                                                                                                                                                                     
                                                                                                                                                                                                                  
test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/deps/hash-da1e5eadb26ad3bb                                                                                                                                                              
                                                                                                                                                                                                                  
running 2 tests
test hasher::checksum_hashcrc32 ... ok
test hasher::checksum_hashcrc64 ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured

   Doc-tests crc                                                                                                                                                                                                  
                                                                                                                                                                                                                  
running 2 tests
test src/lib.rs -  (line 27) ... ok                                                                                                                                                                               
test src/lib.rs -  (line 6) ... ok                                                                                                                                                                                
                                                                                                                                                                                                                  
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured
#

How to calculate the well known CRC-16-CCITT with poly = 0x1021? according to https://www.lammertbies.nl/comm/info/crc-calculation and http://srecord.sourceforge.net/crc16-ccitt.html, we shall get 0xE5CC or 0x29B1 for bytes b"123456789", but I could not manage to get it. The combination I've tried the combination of poly in [0x8408, 0x1021] and init in [0, !0x1D0F], but with no luck.

  fn digest_crc(init: u16, poly: u16, input: &[u8]) -> u16 {
    use crc::crc16::Hasher16;
    let mut digest = crc::crc16::Digest::new_with_initial(poly, init);
    digest.write(input);
    !digest.sum16()
  }
  let input = b"123456789";
  digest_crc(0, 0x1021, input);
  digest_crc(0, 0x8408, input);
  digest_crc(!0x1D0F, 0x1021, input);
  digest_crc(!0x1D0F, 0x8408, input);

I even tried poly of [0x811, 0x8810] according to this https://en.wikipedia.org/wiki/Cyclic_redundancy_check.

Addresses a couple of different issues (https://github.com/mrhooray/crc-rs/pull/37, https://github.com/mrhooray/crc-rs/pull/46, https://github.com/mrhooray/crc-rs/issues/45, https://github.com/mrhooray/crc-rs/issues/40):

• code duplication under the crc16, crc32, and crc64 modules
• dependency on build scripts/macros (multiple Digests can share a crc table)

// Crc

pub trait Width: From<u8> + Into<u64> + Copy + 'static {}
impl Width for u16 {}
impl Width for u32 {}
impl Width for u64 {}

pub struct Algorithm<W: Width> {
    pub poly: W,
    pub init: W,
    pub xorout: W,
    pub check: W,
    pub residue: W,
    pub refin: bool,
    pub refout: bool,
}

pub const CRC_16_IBM_3740: Algorithm<u16> = Algorithm {
    poly: 0x1021, init: 0xffff,
    xorout: 0x0000, check: 0x29b1, residue: 0x0000,
    refin: false, refout: false,
};
pub const CRC_16_AUTOSAR: Algorithm<u16> = CRC_16_IBM_3740;

pub struct Crc<W: Width> {
    algorithm: &'static Algorithm<W>,
    table: [W; 256],
}

impl<W: Width> Crc<W> {
    fn new(algorithm: &'static Algorithm<W>) -> Self {
        let table = make_table(algorithm.poly, algorithm.init);
        Crc { algorithm, table }
    }
}

// Digest

pub struct Digest<'a, W: Width> {
    crc: &'a Crc<W>,
    value: W,
}

impl<'a, W: Width> Digest<'a, W> {
    fn new(crc: &'a Crc<W>) -> Self {
        let value = crc.algorithm.init;
        Digest { crc, value }
    }
}

impl<'a, W: Width> core::hash::Hasher for Digest<'a, W> {
    fn write(&mut self, bytes: &[u8]) {}
    fn finish(&self) -> u64 {
        unimplemented!()
    }
}

fn make_table<W: Width>(poly: W, init: W) -> [W; 256] {
    unimplemented!()
}

This represents a significant change in the API and internal structure of this library, but I believer the advantages are clear. Fully implementing these changes will take quite a bit of work. So, I wanted to get feedback before drafting a PR.

Hello and thank you for the hard work you have put into this crate!

I noticed that the latest commits to the master branch are 8 months old and have not yet been released on crates.io. The new_custom() method has been added to the various digests since the last release, and I think it would be useful to have this method available via downloads from crates.io.

Would it be possible to create a new release? I would be more than happy to help out in anyway possible if there are outstanding issues that need to be resolved first.

On a related note, would you be okay with me opening a pull request to address clippy lint warnings? The changes necessary to resolve the warnings are very minimal and shouldn't require much effort to review.

• extern crate ...; is deprecated.
• Cargo features should be used for "additive" functionality. So, it makes sense to remove the std feature.
• Modifying features requires version bump since it could be a breaking change.

It may sometimes be useful to compute CRC values with an initial value different from the one specified by the used algorithm. In this case, users currently have to create a new Algorithm for each initial value. This is particularly problematic if the initial values are not statically known, since Crc::new takes a static reference to an algorithm (see also #68). With the small change proposed in this PR, an initial value may optionally be supplied when creating a Digest.

I unfortunately lack time for a full repro right now, but maybe this will help. This code:

       let crc = u32::from_le_bytes(data[0..CRC_SIZE].try_into().map_err(|_| Error::DataSize)?);
       let computed_crc = crc32::checksum_ieee(&data[DATA_START..]);

       if crc != computed_crc {
           return Err(Error::Crc);
       }

works right before that commit, but hits the error case after it.

I'd like to replace the following code implementing the 'mpeg2' crc32 with usage the crc-rs crate,

https://github.com/dholroyd/mpeg2ts-reader/blob/master/src/mpegts_crc.rs

Just plugging in the polynomial (0x04C11DB7 I think) didn't seem to work. Are there some extra pre/post processing steps required? I believe I tried inverting the result, but that didn't seem to be correct either.

Thanks!

I had to redefine the polys and expected CRCs for everything in CRC32. However I modified the functions in crc32 so they are all backwards compatible.

The new function new_with_initial_and_final() allows you to generate a reflected table with a custom initial and final XOR value.

@mrhooray Sorry, this is my first pull request and I didn't add a reviewer, assignee, or label.

I'm having trouble getting the crc32 computation to match what I'm seeing in Ceph.
I have an example here where at the top is a C++ unit test and on the bottom is the Rust code I'm using to try and reproduce it. It's close but doesn't match.

https://play.rust-lang.org/?gist=6bca7e3630d48f9225e5&version=stable

This is more of a question rather than an issue.

I have one line code written with v1 API:

let checksum = crc32::update(my_u32, &crc32::IEEE_TABLE, mybytes).to_be_bytes();

I tried to translate to V3 API:

let CRC_32_IEEE: Crc<u32> = Crc::<u32>::new(&CRC_32_ISO_HDLC);
let mut digest = CRC_32_IEEE.digest_with_initial(my_u32);
digest.update(mybytes);
let checksum = digest.finalize();

But the result has changed.

Any ideas? Thanks

Hello,

I'm trying to make a wrapper for a std::io::Write object that keeps a running CRC. This looks something like this:

struct Wrapper<W> {
   w: W,
   crc: Crc<u32>,
}

impl <W: std::io::Write> std::io::Write for Wrapper {
    fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
        self.crc.digest().update(buf);
        self.w.write(buf)
    }
}

However this is wrong, because the running state of the digest gets discarded on every write call (i think). I feel like what I want is crc.update(), but it's not pub. I could also figure out a way to store both the crc and the digest in the struct, but that would involve internal references, which are a pain to work with.

Is there some recommended way to do this? Is this a good case for making Crc::update pub?

Hi,

I did a couple of straight-forward changes such that cargo bench works again. I also fixed the deprecation warnings in the benchmarks ~and changed the rust edition to 2021~.

Let me know if you want anything changed.

So for context, I'm working on a library for a special type of hash which involves a CRC32, but the implementation takes every character and makes it lowercase (ascii_lowercase) before it's hashed. Since this is a const fn, I'm not able to create a new allocations for the lowercased version. I've tried const generics, but that requires always knowing the input length at compile time, which is too restrictive. I've found a way to do this, by adding a const fn version of the update function in Digest, which I've implemented in this PR. Here's an example using it:

pub struct Hash40(pub u64);

pub const fn new(string: &str) -> Hash40 {
    let bytes = string.as_bytes();
    let algo = Crc::<u32>::new(&CRC_32_CKSUM);
    let mut digest = algo.digest();
    let mut index = 0;
    while index < string.len() {
        digest = digest.updated(&[bytes[index]]);
        index += 1;
    }
    let crc = digest.finalize() as u64;
    let length_byte = (string.len() as u8 as u64) << 32;
    Hash40(crc | length_byte)
}

This is kind of an undesirable way to calculate the hash anyway, so if we can find some other way to write this, that would be cool too

This restricts how a program could construct a custom algorithm locally ands use it on the fly.

I noticed that the current internal of Crc holds the reference. Relaxing the lifetime means Crc would need a lifetime parameter as well, which is a breaking change unfortunately. An alternative way is to let Crc clone the data Algorithm has.