Provided by: manpages-posix_2013a-2_all bug


       This  manual  page  is part of the POSIX Programmer's Manual.  The Linux implementation of
       this interface may differ (consult the corresponding Linux  manual  page  for  details  of
       Linux behavior), or the interface may not be implemented on Linux.


       cksum — write file checksums and sizes


       cksum [file...]


       The  cksum  utility shall calculate and write to standard output a cyclic redundancy check
       (CRC) for each input file, and also write to standard output the number of octets in  each
       file.  The  CRC  used  is  based  on  the  polynomial  used  for CRC error checking in the
       ISO/IEC 8802‐3:1996 standard (Ethernet).

       The encoding for the CRC checksum is defined by the generating polynomial:


       Mathematically, the CRC value corresponding to a  given  file  shall  be  defined  by  the
       following procedure:

        1. The n bits to be evaluated are considered to be the coefficients of a mod 2 polynomial
           M(x) of degree n−1.  These  n  bits  are  the  bits  from  the  file,  with  the  most
           significant  bit being the most significant bit of the first octet of the file and the
           last bit being the least significant bit of the last octet, padded with zero bits  (if
           necessary)  to  achieve  an  integral number of octets, followed by one or more octets
           representing the length of the file as a binary value, least significant octet  first.
           The smallest number of octets capable of representing this integer shall be used.

        2. M(x)  is  multiplied  by x32 (that is, shifted left 32 bits) and divided by G(x) using
           mod 2 division, producing a remainder R(x) of degree ≤ 31.

        3. The coefficients of R(x) are considered to be a 32-bit sequence.

        4. The bit sequence is complemented and the result is the CRC.




       The following operand shall be supported:

       file      A pathname of a file to be checked. If  no  file  operands  are  specified,  the
                 standard input shall be used.


       The standard input shall be used if no file operands are specified, and shall be used if a
       file operand is '−' and the implementation treats  the  '−'  as  meaning  standard  input.
       Otherwise, the standard input shall not be used.  See the INPUT FILES section.


       The input files can be any file type.


       The following environment variables shall affect the execution of cksum:

       LANG      Provide a default value for the internationalization variables that are unset or
                 null.  (See  the  Base  Definitions  volume  of   POSIX.1‐2008,   Section   8.2,
                 Internationalization   Variables  for  the  precedence  of  internationalization
                 variables used to determine the values of locale categories.)

       LC_ALL    If set to a non-empty string  value,  override  the  values  of  all  the  other
                 internationalization variables.

       LC_CTYPE  Determine  the  locale for the interpretation of sequences of bytes of text data
                 as characters (for example, single-byte as opposed to multi-byte  characters  in

                 Determine  the  locale  that should be used to affect the format and contents of
                 diagnostic messages written to standard error.

       NLSPATH   Determine the location of message catalogs for the processing of LC_MESSAGES.




       For each file processed successfully, the cksum  utility  shall  write  in  the  following

           "%u %d %s\n", <checksum>, <# of octets>, <pathname>

       If no file operand was specified, the pathname and its leading <space> shall be omitted.


       The standard error shall be used only for diagnostic messages.






       The following exit values shall be returned:

        0    All files were processed successfully.

       >0    An error occurred.



       The following sections are informative.


       The  cksum  utility  is typically used to quickly compare a suspect file against a trusted
       version of the same, such as to ensure that files  transmitted  over  noisy  media  arrive
       intact.  However,  this  comparison  cannot  be  considered  cryptographically secure. The
       chances of a damaged file producing the same CRC as the  original  are  small;  deliberate
       deception is difficult, but probably not impossible.

       Although  input  files  to  cksum  can  be any type, the results need not be what would be
       expected on character special device files or on file types not described  by  the  System
       Interfaces  volume of POSIX.1‐2008. Since this volume of POSIX.1‐2008 does not specify the
       block size used when doing input, checksums of character special files  need  not  process
       all of the data in those files.

       The  algorithm  is  expressed  in  terms of a bitstream divided into octets.  If a file is
       transmitted between two systems and undergoes any data transformation  (such  as  changing
       little-endian  byte  ordering  to  big-endian),  identical  CRC values cannot be expected.
       Implementations  performing  such  transformations  may  extend  cksum  to   handle   such




       The  following  C-language  program  can  be used as a model to describe the algorithm. It
       assumes that a char is one octet. It also assumes that the entire file  is  available  for
       one  pass  through  the  function.  This  was  done  for  simplicity  in demonstrating the
       algorithm, rather than as an implementation model.

           static unsigned long crctab[] = {
           0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b,
           0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6,
           0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
           0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9, 0x5f15adac,
           0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8, 0x6ed82b7f,
           0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3, 0x709f7b7a,
           0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
           0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58,
           0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033,
           0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027, 0xddb056fe,
           0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95,
           0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1, 0xe13ef6f4,
           0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0,
           0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5,
           0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16,
           0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca, 0x7897ab07,
           0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb, 0x6f52c06c,
           0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1,
           0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,
           0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b,
           0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698,
           0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044, 0x902b669d,
           0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e,
           0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2, 0xc6bcf05f,
           0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34,
           0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80,
           0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb,
           0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f, 0x5c007b8a,
           0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e, 0x21dc2629,
           0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5, 0x3f9b762c,
           0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,
           0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e,
           0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65,
           0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601, 0xdea580d8,
           0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3,
           0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7, 0xae3afba2,
           0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71,
           0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74,
           0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640,
           0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c, 0x7b827d21,
           0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd, 0x6c47164a,
           0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e, 0x18197087,
           0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,
           0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d,
           0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce,
           0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb,
           0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18,
           0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4, 0x89b8fd09,
           0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662,
           0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf,
           0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4

           unsigned long memcrc(const unsigned char *b, size_t n)
           /*  Input arguments:
            *  const unsigned char*   b == byte sequence to checksum
            *  size_t                 n == length of sequence

               register size_t i;
               register unsigned c, s = 0;

               for (i = n; i > 0; −−i) {
                   c = *b++;
                   s = (s << 8) ^ crctab[(s >> 24) ^ c];

               /* Extend with the length of the string. */
               while (n != 0) {
                   c = n & 0377;
                   n >>= 8;
                   s = (s << 8) ^ crctab[(s >> 24) ^ c];

               return ~s;

       The historical practice of writing the number of ``blocks'' has been  changed  to  writing
       the  number of octets, since the latter is not only more useful, but also since historical
       implementations have not been consistent in defining what a ``block'' meant.

       The algorithm used was selected to increase the operational robustness of cksum.   Neither
       the  System  V  nor  BSD sum algorithm was selected. Since each of these was different and
       each was the default behavior on those systems, no realistic compromise was  available  if
       either  were selected—some set of historical applications would break. Therefore, the name
       was changed to cksum.  Although the historical sum commands will probably continue  to  be
       provided  for  many years, programs designed for portability across systems should use the
       new name.

       The algorithm  selected  is  based  on  that  used  by  the  ISO/IEC 8802‐3:1996  standard
       (Ethernet)  for  the  frame  check  sequence  field. The algorithm used does not match the
       technical definition of a checksum; the term is used for historical reasons. The length of
       the  file  is included in the CRC calculation because this parallels inclusion of a length
       field by Ethernet in its CRC, but also because it guards  against  inadvertent  collisions
       between  files  that  begin  with  different  series  of  zero octets. The chance that two
       different files produce identical  CRCs  is  much  greater  when  their  lengths  are  not
       considered.  Keeping the length and the checksum of the file itself separate would yield a
       slightly more robust algorithm, but historical usage has always been that a single  number
       (the  checksum  as  printed)  represents  the  signature  of the file. It was decided that
       historical usage was the more important consideration.

       Early proposals contained modifications to the Ethernet algorithm that involved extracting
       table values whenever an intermediate result became zero. This was demonstrated to be less
       robust than the current method and mathematically difficult to describe or justify.

       The calculation used is identical to that given in pseudo-code in the  referenced  Sarwate
       article. The pseudo-code rendition is:

           X <− 0; Y <− 0;
           for i <− m −1 step −1 until 0 do
               T <− X(1) ^ A[i];
               X(1) <− X(0); X(0) <− Y(1); Y(1) <− Y(0); Y(0) <− 0;
               comment: f[T] and f'[T] denote the T-th words in the
                   table f and f' ;
               X <− X ^ f[T]; Y <− Y ^ f'[T];

       The  pseudo-code  is reproduced exactly as given; however, note that in the case of cksum,
       A[i] represents a byte of the file, the words X and Y  are  treated  as  a  single  32-bit
       value, and the tables f and f' are a single table containing 32-bit values.

       The referenced Sarwate article also discusses generating the table.




       The Base Definitions volume of POSIX.1‐2008, Chapter 8, Environment Variables


       Portions  of  this  text  are  reprinted  and  reproduced in electronic form from IEEE Std
       1003.1, 2013 Edition, Standard for Information Technology  --  Portable  Operating  System
       Interface  (POSIX),  The Open Group Base Specifications Issue 7, Copyright (C) 2013 by the
       Institute of Electrical and Electronics Engineers, Inc  and  The  Open  Group.   (This  is
       POSIX.1-2008  with  the  2013  Technical  Corrigendum  1  applied.)  In  the  event of any
       discrepancy between this version and the original IEEE and The Open  Group  Standard,  the
       original  IEEE  and The Open Group Standard is the referee document. The original Standard
       can be obtained online at .

       Any typographical or formatting errors that appear in this page are most  likely  to  have
       been  introduced  during  the conversion of the source files to man page format. To report
       such errors, see .