< prev index next >

src/java.desktop/share/native/libjavajpeg/jchuff.c

Print this page
rev 49276 : [mq]: 8200052-fix-warning-in-jchuff.c


 788         ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW);
 789 
 790       bits[codesize[i]]++;
 791     }
 792   }
 793 
 794   /* JPEG doesn't allow symbols with code lengths over 16 bits, so if the pure
 795    * Huffman procedure assigned any such lengths, we must adjust the coding.
 796    * Here is what the JPEG spec says about how this next bit works:
 797    * Since symbols are paired for the longest Huffman code, the symbols are
 798    * removed from this length category two at a time.  The prefix for the pair
 799    * (which is one bit shorter) is allocated to one of the pair; then,
 800    * skipping the BITS entry for that prefix length, a code word from the next
 801    * shortest nonzero BITS entry is converted into a prefix for two code words
 802    * one bit longer.
 803    */
 804 
 805   for (i = MAX_CLEN; i > 16; i--) {
 806     while (bits[i] > 0) {
 807       j = i - 2;                /* find length of new prefix to be used */
 808       while (bits[j] == 0)
 809         j--;
 810 
 811       bits[i] -= 2;             /* remove two symbols */
 812       bits[i-1]++;              /* one goes in this length */
 813       bits[j+1] += 2;           /* two new symbols in this length */
 814       bits[j]--;                /* symbol of this length is now a prefix */
 815     }
 816   }
 817 
 818   /* Remove the count for the pseudo-symbol 256 from the largest codelength */
 819   while (bits[i] == 0)          /* find largest codelength still in use */
 820     i--;
 821   bits[i]--;
 822 
 823   /* Return final symbol counts (only for lengths 0..16) */
 824   MEMCOPY(htbl->bits, bits, SIZEOF(htbl->bits));
 825 
 826   /* Return a list of the symbols sorted by code length */
 827   /* It's not real clear to me why we don't need to consider the codelength
 828    * changes made above, but the JPEG spec seems to think this works.




 788         ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW);
 789 
 790       bits[codesize[i]]++;
 791     }
 792   }
 793 
 794   /* JPEG doesn't allow symbols with code lengths over 16 bits, so if the pure
 795    * Huffman procedure assigned any such lengths, we must adjust the coding.
 796    * Here is what the JPEG spec says about how this next bit works:
 797    * Since symbols are paired for the longest Huffman code, the symbols are
 798    * removed from this length category two at a time.  The prefix for the pair
 799    * (which is one bit shorter) is allocated to one of the pair; then,
 800    * skipping the BITS entry for that prefix length, a code word from the next
 801    * shortest nonzero BITS entry is converted into a prefix for two code words
 802    * one bit longer.
 803    */
 804 
 805   for (i = MAX_CLEN; i > 16; i--) {
 806     while (bits[i] > 0) {
 807       j = i - 2;                /* find length of new prefix to be used */
 808       while ((bits[j] == 0) && (j > 0))
 809         j--;
 810 
 811       bits[i] -= 2;             /* remove two symbols */
 812       bits[i-1]++;              /* one goes in this length */
 813       bits[j+1] += 2;           /* two new symbols in this length */
 814       bits[j]--;                /* symbol of this length is now a prefix */
 815     }
 816   }
 817 
 818   /* Remove the count for the pseudo-symbol 256 from the largest codelength */
 819   while (bits[i] == 0)          /* find largest codelength still in use */
 820     i--;
 821   bits[i]--;
 822 
 823   /* Return final symbol counts (only for lengths 0..16) */
 824   MEMCOPY(htbl->bits, bits, SIZEOF(htbl->bits));
 825 
 826   /* Return a list of the symbols sorted by code length */
 827   /* It's not real clear to me why we don't need to consider the codelength
 828    * changes made above, but the JPEG spec seems to think this works.


< prev index next >