504 lines
24 KiB
Plaintext
Executable File
504 lines
24 KiB
Plaintext
Executable File
[library Boost.CRC
|
|
[quickbook 1.5]
|
|
[version 1.5]
|
|
[id crc]
|
|
[dirname crc]
|
|
[copyright 2001 2003 2012 Daryle Walker]
|
|
[purpose Cyclic Redundancy Code computation]
|
|
[category Miscellaneous]
|
|
[authors [Walker, Daryle]]
|
|
[license
|
|
Distributed under the Boost Software License, Version 1.0.
|
|
(See the accompanying file LICENSE_1_0.txt or a copy at
|
|
[@http://www.boost.org/LICENSE_1_0.txt])
|
|
]
|
|
[source-mode c++]
|
|
]
|
|
|
|
[/ Macros ]
|
|
[def __RMCA__ Rocksoft\u2122 Model CRC Algorithm]
|
|
|
|
[section:motivation What is Boost.CRC?]
|
|
|
|
CRCs (cyclic redundancy codes) is one common technique to confirming data
|
|
integrity after transmission. The [*Boost.CRC] library provides access to two
|
|
styles of CRC computation, one as a function template, the other as a function
|
|
template and two computation object class templates, where the two class
|
|
templates differ in speed.
|
|
|
|
[endsect]
|
|
[section:introduction Introduction]
|
|
|
|
[note
|
|
Some of the introductory material is based on
|
|
[@http://www.ross.net/crc/download/crc_v3.txt ['A Painless Guide to CRC
|
|
Error Detection Algorithms]] by Ross N. Williams at his
|
|
[@http://www.ross.net/crc/ [*The CRC Pitstop]] site.
|
|
]
|
|
|
|
When binary data is transmitted, usually electronically, there is a chance that
|
|
the data gets corrupted. One method to pick up said corruption is to generate
|
|
some value that is coded from the original data, send said value to the
|
|
receiver, then confirm that the received data generates the same value when it's
|
|
coded at the destination.
|
|
|
|
There are several possibilities after the receiver's check:
|
|
|
|
* The check value matches at both places and the data was transmitted intact.
|
|
* The data got corrupted and the check values do not match.
|
|
* The data is intact, but the check value got corrupted. This can't the
|
|
distinguished from the previous case, but is a (relatively) safe false
|
|
positive.
|
|
* Either the data and/or check value gets corrupted, but such that the results
|
|
of the check-coding are still consistent. This is a dangerous false negative!
|
|
|
|
The way to minimize false negatives is to choose coding algorithms that cause a
|
|
lot of churn per input, especially a variable amount.
|
|
|
|
The check values are known as [*checksum]s because they are used to /check/ for
|
|
data consistency and the first coding algorithms were addition- (i.e.
|
|
['sum]ming-) based.
|
|
|
|
[section:intro_crcs CRCs]
|
|
|
|
[*Cyclic Redundancy Codes] are a type of consistency check that treats the
|
|
message data as a (long) dividend of a modulo-2 polynomial division. Modulo-2
|
|
arithmetic doesn't use carries/borrows when combining numbers. A specific CRC
|
|
defines a set number of bits to work on at a time, where said number is also the
|
|
degree of a fixed polynomial (with modulo-2 coefficients) used as a divisor.
|
|
|
|
Since ordering doesn't apply to modulo arithmetic, the check between the current
|
|
high part of the dividend and the trial partial product (of the divisor and the
|
|
trial new quotient coefficient) is done by seeing if the highest-degree
|
|
coefficient of the dividend is one. (The highest-degree coefficient of the
|
|
divisor must be one by definition, since it's the only non-zero choice.) The
|
|
remainder after the division is finished is used as the basis of the CRC
|
|
checksum.
|
|
|
|
[section:intro_crcs_impl CRC Implementation]
|
|
|
|
For a given degree /x/ for the modulo-2 polynomial divisor, the remainder will
|
|
have at most /x/ terms (from degree /x/ - 1 down to the constant term). The
|
|
coefficients are modulo-2, which means that they can be represented by 0's and
|
|
1's. So a remainder can be modeled by an (unsigned) integer of at least /x/
|
|
bits in *width*.
|
|
|
|
The divisor must have its /x/ degree term be one, which means it is always known
|
|
and can be implied instead of having to explicitly include in representations.
|
|
Its lower /x/ terms must be specified, so a divisor can be modeled the same way
|
|
as remainders. With such a modeling, the divisor representation could be said
|
|
to be truncated since the uppermost term's value is implied and not stored.
|
|
|
|
The remainder and [*(truncated) divisor polynomial]s are stored as basic
|
|
computer integers. This is in contrast to the dividend, which is modeled from
|
|
the input stream of data bits, where each new incoming bit is the next lower
|
|
term of the dividend polynomial. Long division can be processed in piecemeal,
|
|
reading new upper terms as needed. This maps to reading the data a byte (or
|
|
bit) at a time, generating updated remainders just-in-time, without needing to
|
|
read (and/or store(!)) the entire data message at once.
|
|
|
|
Long division involves appending new dividend terms after the previous terms
|
|
have been processed into the (interim) remainder. So the remainder it the only
|
|
thing that has to change during each division step; a new input byte (or bit) is
|
|
combined with the remainder to make the interim dividend, and then combined with
|
|
the partial product (based on the divisor and top dividend bit(s)) to become a
|
|
remainder again.
|
|
|
|
[endsect]
|
|
[section:intro_crcs_augment Message Augmentation]
|
|
|
|
When all of the input data has been read during division, the last /x/ bits are
|
|
still stuck in the interim remainder. They have not been pushed through the
|
|
division steps; to do so, /x/ zero-valued extra bits must be passed into the
|
|
system. This ensures all of the message's data bits get processed. The
|
|
post-processed remainder is the checksum. The system requires the message to be
|
|
*augmented* with /x/ extra bits to get results.
|
|
|
|
Alternatively, if the post-division augmentation bits are the expected checksum
|
|
instead, then the remainder will "subtract" the checksum with itself, giving
|
|
zero as the final remainder. The remainder will end up non-zero if bit errors
|
|
exist in either the data or checksum or both. This option requires the checksum
|
|
to be fed from highest-order bit first on down (i.e. big endian).
|
|
|
|
Exploiting the properties of how the division is carried out, the steps can be
|
|
rearranged such that the post-processing zero-valued bits are not needed; their
|
|
effect is merged into the start of the process. Such systems read *unaugmented*
|
|
messages and expose the checksum directly from the interim remainder afterwards.
|
|
(You can't use the "augment-message-with-checksum-and-zero-check" technique with
|
|
this, of course.)
|
|
|
|
[endsect]
|
|
[section:intro_crcs_param Other CRC Parameters]
|
|
|
|
Since long division proceeds from the uppermost terms on down, it's easiest to
|
|
treat an incoming byte as the uppermost unprocessed terms, and to read the bits
|
|
within that byte as the highest-order bit is the uppermost unprocessed term and
|
|
go down. However, some hardware implementations have an easier time reading
|
|
each byte from the lowest-order bit and go up. To simulate those systems in
|
|
software, the program needs to be flagged that *input reflection* needs to be
|
|
applied. Reflecting a built-in integer reverses the order of its bits, such
|
|
that the lowest- and highest-order bits swap states, the next-lowest- and
|
|
next-highest-order bits swap, etc. The input reflection can be done by
|
|
reflecting each byte as it comes in or keeping the bytes unchanged but reflect
|
|
the other internal functioning. The latter sounds harder, but what it usually
|
|
done in the real world, since it's a one-time cost, unlike reflecting the bytes.
|
|
|
|
Similarly, the final remainder is processed by some hardware in reverse order,
|
|
which means software that simulate such systems need to flag that *output
|
|
reflection* is in effect.
|
|
|
|
Some CRCs don't return the remainder directly (reflected or not), but add an
|
|
extra step complementing the output bits. Complementing turns 1 values into 0
|
|
values and vice versa. This can simulated by using a XOR (exclusive-or) bit
|
|
mask of all 1-values (of the same bit length as the remainder). Some systems
|
|
use a *final XOR mask* that isn't all 1-values, for variety. (This mask takes
|
|
place /after/ any output reflection.)
|
|
|
|
At the other end, the built-in-integer register normally starts at zero as the
|
|
first bytes are read. Instead of just doing nothing but load input bits for /x/
|
|
steps, some CRC systems use a non-zero *initial remainder* to add extra
|
|
processing. This initial value has to be different for the augmented versus
|
|
un-augmented versions of the same system, due to possible incorporation with the
|
|
zero-valued augment bits.
|
|
|
|
[endsect]
|
|
[section:intro_crcs_rmca Compact CRC Parameter Specification]
|
|
|
|
The __RMCA__, or RMCA for short, was designed by Ross Williams to describe all
|
|
the specification points of a given CRC system (quoted):
|
|
|
|
[variablelist RMCA Parameters
|
|
[[WIDTH] [This is the width of the algorithm expressed in bits. This
|
|
is one less than the width of the Poly.]]
|
|
[[POLY] [This parameter is the poly. This is a binary value that
|
|
should be specified as a hexadecimal number. The top bit of the
|
|
poly should be omitted. For example, if the poly is 10110, you
|
|
should specify 06. An important aspect of this parameter is that it
|
|
represents the unreflected poly; the bottom bit of this parameter
|
|
is always the LSB of the divisor during the division regardless of
|
|
whether the algorithm being modelled is reflected.]]
|
|
[[INIT] [This parameter specifies the initial value of the register
|
|
when the algorithm starts. This is the value that is to be assigned
|
|
to the register in the direct table algorithm. In the table
|
|
algorithm, we may think of the register always commencing with the
|
|
value zero, and this value being XORed into the register after the
|
|
N'th bit iteration. This parameter should be specified as a
|
|
hexadecimal number.]]
|
|
[[REFIN] [This is a boolean parameter. If it is FALSE, input bytes are
|
|
processed with bit 7 being treated as the most significant bit
|
|
(MSB) and bit 0 being treated as the least significant bit. If this
|
|
parameter is FALSE, each byte is reflected before being processed.]]
|
|
[[REFOUT] [This is a boolean parameter. If it is set to FALSE, the
|
|
final value in the register is fed into the XOROUT stage directly,
|
|
otherwise, if this parameter is TRUE, the final register value is
|
|
reflected first.]]
|
|
[[XOROUT] [This is an W-bit value that should be specified as a
|
|
hexadecimal number. It is XORed to the final register value (after
|
|
the REFOUT) stage before the value is returned as the official
|
|
checksum.]]
|
|
]
|
|
|
|
His description assumes an octet-sized byte. The /POLY/ is the (truncated)
|
|
divisor. The /INIT/ is the initial remainder, assuming the unaugmented version
|
|
of CRC processing is used. (If you're using an augmented-style CRC, you have to
|
|
undo the effect of the built-in zero-augment before initialization.)
|
|
|
|
[endsect]
|
|
|
|
The two function templates and two class templates in this library provide ways
|
|
to carry out CRC computations. You give the various __RMCA__ parameters as
|
|
template parameters and/or constructor parameters. You then submit all the
|
|
message data bytes at once (for the functions) or piecemeal (for the class
|
|
objects).
|
|
|
|
[endsect]
|
|
|
|
Note that some error-detection techniques merge their checksum results within
|
|
the message data, while CRC checksums are either at the end (when augmented,
|
|
without either kind of reflection, with a bit-width that's a multiple of byte
|
|
size, and no XOR mask) or out-of-band.
|
|
|
|
[endsect]
|
|
[section:crc_basic Theoretical CRC Computer]
|
|
|
|
#include <cstddef> // for std::size_t
|
|
|
|
namespace boost
|
|
{
|
|
template < std::size_t Bits >
|
|
class crc_basic;
|
|
}
|
|
|
|
The [*`boost::crc_basic`] class template acts as an unaugmented-CRC processor
|
|
that can accept input at the bit-level. It only takes one __RMCA__ parameter as
|
|
a template parameter, the /WIDTH/, which determines the built-in unsigned integer
|
|
type used for division registers. The other __RMCA__ parameters can be passed
|
|
on through the constructor. (Most of the parameters have defaults.)
|
|
|
|
The integer type used for registers is published as `value_type`, while the
|
|
__RMCA__ attributes can be discovered as:
|
|
|
|
[table:crc_basic_rmca RMCA Parameters in boost::crc_basic
|
|
[[Parameter] [Member Name] [Kind] [Expression Type]]
|
|
[[['WIDTH]] [`bit_count`] [class-static immutable data member] [`std::size_t`]]
|
|
[[['POLY]] [`get_truncated_polynominal`] [`const` member function] [`value_type`]]
|
|
[[['INIT]] [`get_initial_remainder`] [`const` member function] [`value_type`]]
|
|
[[['REFIN]] [`get_reflect_input`] [`const` member function] [`bool`]]
|
|
[[['REFOUT]] [`get_reflect_remainder`] [`const` member function] [`bool`]]
|
|
[[['XOROUT]] [`get_final_xor_value`] [`const` member function] [`value_type`]]
|
|
]
|
|
|
|
Since most of the parameters are specified at run-time, you can reuse a single
|
|
computer object for separate runs with differing parameters. The type uses the
|
|
automatically-defined copy/move/assign and destruction routines.
|
|
|
|
[import ./crc_examples.cpp]
|
|
[crc_basic_reuse]
|
|
|
|
This example necessarily demonstrates input and output. There is one output
|
|
member function, `checksum` that returns the remainder from the CRC steps plus
|
|
any post-processing reflection and/or XOR-masking. There are several options
|
|
to submit input data for processing:
|
|
|
|
[table:crc_basic_input Member Functions for Input in boost::crc_basic
|
|
[[Member Function] [Input Type/Style]]
|
|
[[`process_bit`] [A single bit.]]
|
|
[[`process_bits`] [A specified number of bits within the given byte.
|
|
Reading starts from the highest-order desired bit.]]
|
|
[[`process_byte`] [An entire byte. The bits within the byte are read in an
|
|
order consistent with `get_reflect_input`.]]
|
|
[[`process_block`] [All bytes in the range. The range is defined by a
|
|
pointer to the first byte and another pointer to one (byte) past-the-end.]]
|
|
[[`process_bytes`] [All bytes in the range. The range is defined by a
|
|
pointer to the first byte and a count of number of bytes to read.]]
|
|
]
|
|
|
|
The input functions currently do not return anything.
|
|
|
|
[crc_piecemeal_run]
|
|
|
|
The input-influenced state of a computer object may be read with the
|
|
`get_interim_remainder` member function. An object may be loaded with the same
|
|
kind of state with the one-argument version of the `reset` member function.
|
|
The state is the remainder from the CRC operations performed on all the
|
|
already-entered input, without any output post-processing.
|
|
|
|
The two functions can be used together to save the state to a persistent medium
|
|
and restore it later. Note that the __RMCA__ parameters have to saved/restored
|
|
via other means, if they're not fixed within a program.
|
|
|
|
Calling `reset` with no arguments sets the interim remainder to what /INIT/ was
|
|
set at object construction. This lets one computer object be used for
|
|
independent runs with separate data messages using the same CRC standard.
|
|
|
|
[endsect]
|
|
[section:crc_optimal Optimized CRC Computer]
|
|
|
|
#include <boost/cstdint.hpp> // for boost::uintmax_t
|
|
#include <cstddef> // for std::size_t
|
|
|
|
namespace boost
|
|
{
|
|
template < std::size_t Bits, uintmax_t TruncPoly, uintmax_t InitRem,
|
|
uintmax_t FinalXor, bool ReflectIn, bool ReflectRem >
|
|
class crc_optimal;
|
|
}
|
|
|
|
The [*`boost::crc_optimal`] class template acts as an unaugmented-CRC processor
|
|
that can accept input at the byte-level. It takes all the __RMCA__ parameters
|
|
as template parameters. Like in `crc_basic`, the /WIDTH/ stays as the first
|
|
parameter and determines the built-in unsigned integer type used for division
|
|
registers. The other __RMCA__ parameters move up to the template parameter
|
|
field in the same relative order they were in the `crc_basic` constructor.
|
|
(Some parameters have defaults.) Objects based from `crc_optimal` can either be
|
|
default-constructed, giving it the same behavior as a `crc_basic` object with
|
|
the equivalent settings, or use one parameter, which overrides the initial
|
|
remainder value[footnote i.e. The interim-remainder before any input is read.]
|
|
without permanently affecting the initial-remainder attribute.
|
|
|
|
Besides template parameters and construction, `crc_optimal` differs from
|
|
`crc_basic` interface-wise by:
|
|
|
|
* Adding five class-static immutable data members corresponding to the new
|
|
template parameters.
|
|
[table:crc_optimal_rmca Additional RMCA Expressions in boost::crc_optimal
|
|
[[New Member] [Equivalent]]
|
|
[[`truncated_polynominal`] [`get_truncated_polynominal`]]
|
|
[[`initial_remainder`] [`get_initial_remainder`]]
|
|
[[`reflect_input`] [`get_reflect_input`]]
|
|
[[`reflect_remainder`] [`get_reflect_remainder`]]
|
|
[[`final_xor_value`] [`get_final_xor_value`]]
|
|
]
|
|
* Removing the `process_bit` and `process_bits` member functions.
|
|
* Adding two versions of the `operator ()` member function. The single-argument
|
|
version forwards to `process_byte`, making it suitable to STL algorithms that
|
|
take (and possibly return) function objects[footnote Like `std::for_each`.].
|
|
The argument-less version forwards to `checksum`, making it suitable for STL
|
|
algorithms that expect generator objects[footnote Albeit this object won't
|
|
change its return value within code that only uses it as a generator.].
|
|
* Merging the two `reset` member functions into one. (It uses a single
|
|
parameter that can have a default argument).
|
|
|
|
The major difference between `crc_basic` and `crc_optimal` is the internals.
|
|
Objects from `crc_basic` run their CRC algorithm one bit at a time, no matter
|
|
which unit is used as input. Objects from `crc_optimal`, when /WIDTH/ is at
|
|
least `CHAR_BIT`[footnote i.e. The optimizations are suspended if the /WIDTH/
|
|
only justifies using part of a single byte.], use a byte-indexed table-driven CRC
|
|
algorithm which is a *lot* faster than processing individual bits.
|
|
|
|
Since all of the parameters are specified at compile-time, you cannot reuse a
|
|
single computer object for separate runs with differing parameters. The type
|
|
uses the automatically-defined copy/move/assign and destruction routines.
|
|
|
|
[endsect]
|
|
[section:crc_function CRC Function]
|
|
|
|
#include <boost/cstdint.hpp> // for boost::uintmax_t
|
|
#include <boost/integer.hpp> // for boost::uint_t
|
|
#include <cstddef> // for std::size_t
|
|
|
|
namespace boost
|
|
{
|
|
template < std::size_t Bits, uintmax_t TruncPoly, uintmax_t InitRem,
|
|
uintmax_t FinalXor, bool ReflectIn, bool ReflectRem >
|
|
typename uint_t<Bits>::fast crc( void const *buffer, std::size_t
|
|
byte_count );
|
|
}
|
|
|
|
The [*`boost::crc`] function template computes the unaugmented CRC of a single
|
|
data block in one pass. It has the same template parameter list as
|
|
`boost::crc_optimal`, which it uses for implementation. This function saves you
|
|
the trouble of setting up and using the `boost::crc_optimal` object manually.
|
|
|
|
[endsect]
|
|
[section:acrc_function Augmented-CRC Function]
|
|
|
|
#include <boost/cstdint.hpp> // for boost::uintmax_t
|
|
#include <boost/integer.hpp> // for boost::uint_t
|
|
#include <cstddef> // for std::size_t
|
|
|
|
namespace boost
|
|
{
|
|
template < std::size_t Bits, uintmax_t TruncPoly >
|
|
typename uint_t<Bits>::fast augmented_crc( void const *buffer,
|
|
std::size_t byte_count, typename uint_t<Bits>::fast initial_remainder
|
|
= 0u );
|
|
}
|
|
|
|
The [*`boost::augmented_crc`] function computes the augmented-style CRC of a
|
|
data block. Like `boost::crc`, the first two template parameters are the
|
|
/WIDTH/ and /POLY/. However, the /INIT/ has moved to being a function
|
|
parameter, after the data block's starting address and byte length, defaulting
|
|
to zero if not given.
|
|
|
|
This function uses modulo-2 division at its most raw, and so forfeits the
|
|
/REFIN/, /REFOUT/, and /XOROUT/ attributes, setting them to `0` or `false`.
|
|
Another difference from `boost::crc` is that a non-zero /INIT/ has to be skewed
|
|
when used with this function. (No conversion functions are currently given.)
|
|
|
|
[acrc_piecemeal_run]
|
|
|
|
Since `augmented_crc` doesn't know when your data ends, you must supply the
|
|
augment, either /WIDTH/ zero bits or the expected checksum. The augment can be
|
|
either at the end of last data block or from an extra call. Remember that if an
|
|
expected checksum is used as the augment, its bits must be arranged in
|
|
big-endian order. Because `augmented_crc` reads byte-wise, while augments
|
|
assume bit-wise reading, augmentations are valid only when /WIDTH/ is a multiple
|
|
of the bits-per-byte ratio (`CHAR_BIT`).
|
|
|
|
[endsect]
|
|
[section:crc_samples Pre-Defined CRC Samples]
|
|
|
|
namespace boost
|
|
{
|
|
typedef crc_optimal<16, 0x8005, 0, 0, true, true>
|
|
crc_16_type;
|
|
|
|
typedef crc_optimal<16, 0x1021, 0xFFFF, 0, false, false>
|
|
crc_ccitt_false_t, crc_ccitt_type;
|
|
typedef crc_optimal<16, 0x1021, 0, 0, true, true> crc_ccitt_true_t;
|
|
|
|
typedef crc_optimal<16, 0x8408, 0, 0, true, true> crc_xmodem_type;
|
|
typedef crc_optimal<16, 0x1021, 0, 0, false, false> crc_xmodem_t;
|
|
|
|
typedef crc_optimal<32, 0x04C11DB7, 0xFFFFFFFF, 0xFFFFFFFF, true, true>
|
|
crc_32_type;
|
|
}
|
|
|
|
Several sample CRC types are given, representing common CRC algorithms. The
|
|
samples have now been checked against the
|
|
[@http://regregex.bbcmicro.net/crc-catalogue.htm ['Catalogue of parametrised CRC
|
|
algorithms]], leading to some new type-aliases corresponding to the corrected
|
|
profiles. (Older, incorrect profiles keep their name for backwards
|
|
compatibility.) However, this library is primarily concerned with CRC
|
|
implementation, and not with determining "good" sets of CRC parameters.
|
|
|
|
[table:crc_samples_list Common CRCs
|
|
[[Computer Type] [Standard(s)]]
|
|
[[`crc_16_type`] [BISYNCH, ARC, LHA, ZOO]]
|
|
[[`crc_ccitt_false_t`] [Commonly misidentified as the standard by CCITT]]
|
|
[[`crc_ccitt_type`] [`crc_ccitt_false_t` (I made the same mistake.)]]
|
|
[[`crc_ccitt_true_t`] [Designated by CCITT (Comit\u00E9 Consultatif
|
|
International T\u00E9l\u00E9graphique et T\u00E9l\u00E9phonique), KERMIT]]
|
|
[[`crc_xmodem_type`] [A mistake I didn't catch in defining
|
|
`crc_xmodem_t`.]]
|
|
[[`crc_xmodem_t`] [XMODEM, ZMODEM, ACORN]]
|
|
[[`crc_32_type`] [ADCCP, PKZip, libPNG, AUTODIN II, Ethernet, FDDI]]
|
|
]
|
|
|
|
[endsect]
|
|
[section:end End Matter]
|
|
[heading References]
|
|
|
|
*The [@boost:/boost/crc.hpp CRC header] itself
|
|
*Some [@boost:/libs/crc/test/crc_test.cpp test code] and some
|
|
[@boost:/libs/crc/test/crc_test2.cpp newer tests] that use the
|
|
[@boost:/libs/test/index.html Boost test library]
|
|
*Some [@boost:/libs/crc/crc_example.cpp example code]
|
|
|
|
[variablelist History
|
|
[[Boost 1.49.0] [Refined implementation, testing, and documentation. Some
|
|
interfaces were tweaked.]]
|
|
[[Boost 1.30.2 (estimated)] [Released an example program.]]
|
|
[[Boost 1.22.0] [First public release.]]
|
|
]
|
|
|
|
[heading Acknowledgments]
|
|
|
|
For giving advice on compiler/C++ compliance, implementation, interface,
|
|
algorithms, and bug reports:
|
|
|
|
*Darin Adler
|
|
*Beman Dawes
|
|
*Doug Gregor
|
|
*John Maddock
|
|
*Joe Mariadassou
|
|
*Jens Maurer
|
|
*Vladimir Prus
|
|
*Joel Young
|
|
|
|
[variablelist Contributors
|
|
[[Michael Barr [@mailto:mbarr@netrino.com mbarr@netrino.com]]
|
|
[Wrote
|
|
[@http://www.netrino.com/Embedded-Systems/How-To/CRC-Calculation-C-Code
|
|
["CRC Implementation Code in C]], a less-confusing guide to implementing
|
|
CRC algorithms. (Originally published as ["Slow and Steady Never Lost the
|
|
Race] in the January 2000 issue of [@http://www.embedded.com ['Embedded
|
|
Systems Programming]], pages 37\u201346. The web version used to be known
|
|
as [@http://www.netrino.com/Connecting/2000-01/ ['Easier Said Than Done]].)
|
|
]]
|
|
[[Daryle Walker]
|
|
[Started the library and contributed the theoretical and optimal CRC
|
|
computation class templates and the CRC computing function template.
|
|
Contributed the test and example code.
|
|
]]
|
|
[[Ross N. Williams]
|
|
[Wrote [@http://www.ross.net/crc/crcpaper.html ['A Painless Guide to CRC
|
|
Error Detection Algorithms]], a definitive source of CRC information.
|
|
]]
|
|
]
|
|
|
|
[endsect]
|
|
|
|
[xinclude autodoc.xml]
|