Struct PrintImpl 

pub struct PrintImpl<'a, ExtField = Fe1024> { /* private fields */ }

Given a polynomial representation for your generator polynomial and your target residue, outputs a impl Checksum block.

You must specify an extension field. You should try crate::Fe1024, and if you get an error about a polynomial not splitting, try crate::Fe32768.

Used like

use core::convert::TryFrom;

use bech32::{Fe32, Fe1024, PrintImpl};
use bech32::primitives::checksum::PackedFe32;

// In codes specified in BIPs, the code generator polynomial and residue
// are often only given indirectly, in the reference code which encodes
// it in a packed form (shifted multiple times).
//
// For example in the BIP173 Python reference code you will see an array
// called `generator` whose first entry is 0x3b6a57b2. This first entry
// is the generator polynomial in packed form.
//
// To get the expanded polynomial form you can use `u128::unpack` like so:
let unpacked_poly = (0..6)
    .rev() // Note .rev() to convert from BE integer literal to LE polynomial!
    .map(|i| 0x3b6a57b2u128.unpack(i))
    .map(|u| Fe32::try_from(u).unwrap())
    .collect::<Vec<_>>();
let unpacked_residue = (0..6)
    .rev()
    .map(|i| 0x1u128.unpack(i))
    .map(|u| Fe32::try_from(u).unwrap())
    .collect::<Vec<_>>();
println!(
    "{}",
    PrintImpl::<Fe1024>::new(
        "Bech32",
        &unpacked_poly,
        &unpacked_residue,
    ),
);

The awkward API is to allow this type to be used in the widest set of circumstances, including in nostd settings. (However, the underlying polynomial math requires the alloc feature.)

Both polynomial representations should be in little-endian order, so that the coefficient of x^i appears in the ith slot. The generator polynomial should be a monic polynomial but you should not include the monic term, so that both generator and target are arrays of the same length.

This function should never need to be called by users, but will be helpful for developers.

In general, when defining a checksum, it is best to call this method (and to add a unit test that calls Checksum::sanity_check rather than trying to compute the values yourself. The reason is that the specific values used depend on the representation of extension fields, which may differ between implementations (and between specifications) of your BCH code.

Implementations

impl<'a, ExtField> PrintImpl<'a, ExtField>

pub fn new(name: &'a str, generator: &'a [Fe32], target: &'a [Fe32]) -> Self

Constructor for an object to print an impl-block for the Checksum trait.

Panics

Panics if any of the input values fail various sanity checks.

Trait Implementations

impl<ExtField> Display for PrintImpl<'_, ExtField>

where ExtField: Bech32Field + ExtensionField<BaseField = Fe32>,

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.