Editing Cyclic redundancy check (section)

== Specification ==
The concept of the CRC as an error-detecting code gets complicated when an implementer or standards committee uses it to design a practical system. Here are some of the complications:
*Sometimes an implementation '''prefixes a fixed bit pattern''' to the bitstream to be checked. This is useful when clocking errors might insert 0-bits in front of a message, an alteration that would otherwise leave the check value unchanged.
*Usually, but not always, an implementation '''appends ''n'' 0-bits''' (''n'' being the size of the CRC) to the bitstream to be checked before the polynomial division occurs. Such appending is explicitly demonstrated in the [[Computation of cyclic redundancy checks|Computation of CRC]] article. This has the convenience that the remainder of the original bitstream with the check value appended is exactly zero, so the CRC can be checked simply by performing the polynomial division on the received bitstream and comparing the remainder with zero. Due to the associative and commutative properties of the exclusive-or operation, practical table driven implementations can obtain a result numerically equivalent to zero-appending without explicitly appending any zeroes, by using an equivalent,<ref name="williams93" /> faster algorithm that combines the message bitstream with the stream being shifted out of the CRC register.
*Sometimes an implementation '''exclusive-ORs a fixed bit pattern''' into the remainder of the polynomial division.
*'''Bit order:''' Some schemes view the low-order bit of each byte as "first", which then during polynomial division means "leftmost", which is contrary to our customary understanding of "low-order". This convention makes sense when [[serial port|serial-port]] transmissions are CRC-checked in hardware, because some widespread serial-port transmission conventions transmit bytes least-significant bit first.
*'''[[Byte order]]''': With multi-byte CRCs, there can be confusion over whether the byte transmitted first (or stored in the lowest-addressed byte of memory) is the least-significant byte (LSB) or the most-significant byte (MSB). For example, some 16-bit CRC schemes swap the bytes of the check value.
*'''Omission of the high-order bit''' of the divisor polynomial: Since the high-order bit is always 1, and since an ''n''-bit CRC must be defined by an ({{nowrap|''n'' + 1}})-bit divisor which [[Arithmetic overflow|overflows]] an ''n''-bit [[processor register|register]], some writers assume that it is unnecessary to mention the divisor's high-order bit.
*'''Omission of the low-order bit''' of the divisor polynomial: Since the low-order bit is always 1, authors such as Philip Koopman represent polynomials with their high-order bit intact, but without the low-order bit (the <math>x^0</math> or 1 term).  This convention encodes the polynomial complete with its degree in one integer.

These complications mean that there are three common ways to express a polynomial as an integer: the first two, which are mirror images in binary, are the constants found in code; the third is the number found in Koopman's papers.  ''In each case, one term is omitted.'' So the polynomial <math>x^4 + x + 1</math> may be transcribed as:
*0x3 = 0b0011, representing <math>x^4 + (0x^3 + 0x^2 + 1x^1 + 1x^0)</math> (MSB-first code)
*0xC = 0b1100, representing <math>(1x^0 + 1x^1 + 0x^2 + 0x^3) + x^4</math> (LSB-first code)
*0x9 = 0b1001, representing <math>(1x^4 + 0x^3 + 0x^2 + 1x^1) + x^0</math> (Koopman notation)
In the table below they are shown as:
{|class="wikitable"
|+ Examples of CRC representations
|-
! Name
! Normal
! Reversed
! Reversed reciprocal
|-
| CRC-4
| 0x3
| 0xC
| 0x9
|}