Do you remember that fight I had with David Scott in s.c about a year
ago wrt the code quality of scott19u? (Yes, this is relevant.)

Here's a link that'll drop you right into the middle of it:

http://groups.google.com/groups?q=g:thl1115158400d&selm=39F9F783.1C55...

(You might have to mend it for line wrap.)

As you might recall, Mr Scott jumped through some rather ghastly
gcc-shaped hoops in order to get 19-bit integers, and claimed this could
not be done portably. (About now, I need to say "tee-hee"...) So I
decided to show that it could be.

Here is the source code I presented during that debate (except that I've
mended the line-wrap on the #defines). I think you'll find it's a direct
answer to your question. Admittedly, the test-driver at the bottom uses
19 a lot (guess why), but you should be able to plug 8 straight into it
without difficulty.

Now, just before we get to the code - a quick request. Could we please
conduct this discussion in just *one* newsgroup? Preferably this one,
since you're vastly more on-topic here than in sci.crypt. Thanks.

/* Pretend you can see an LGPL licence here. This code, written by
Richard Heathfield in October 2000, provides routines for packing a
bunch of smaller-than-the-maximum-size ints into a bit array, and for
ripping them out again. */

#include <stdio.h>
#include <limits.h>

#define SET_BIT(a, n) (a)[(n) / CHAR_BIT] |= \
                    (unsigned char)(1U << ((n) % CHAR_BIT))
#define CLEAR_BIT(a, n) (a)[(n) / CHAR_BIT] &= \
                   (unsigned char)(~(1U << ((n) % CHAR_BIT)))
#define TEST_BIT(a, n) (((a)[(n) / CHAR_BIT] & \
                   (unsigned char)(1U << ((n) % CHAR_BIT))) ? 1 : 0)

/* Debugging function, used for printing len * CHAR_BIT
 * bits from s.
 */
int print_bits(unsigned char *s, int len)
{
  int i, j;
  for(i = 0; i < len; i++)
  {
    for(j = 0; j < CHAR_BIT; j++)
    {
      printf("%d", TEST_BIT(s, i * CHAR_BIT + j) ? 1 : 0);
    } printf(" ");
  }
  printf("\n");
  return 0;

  return answer;

  if(n <= BitsInUnsignedInt())
  {
    i += BaseBit;
    BitArray += i / CHAR_BIT;
    i %= CHAR_BIT;

    for(j = 0; j < n; j++)
    {
      /* Move the populated bits out of the way.
       * Yes, this means that the first iteration
       * of the loop does a useless shift. I think
       * I can live with that. :-)
       */
      Value <<= 1;

      /* Populate the low bit */
      Value |= TEST_BIT(BitArray, i + j);
    }
  }

  return Value;

  if(n <= 32)
  {
    i += BaseBit;

    BitArray += i / CHAR_BIT;
    i %= CHAR_BIT;

    j = n;
    while(j--)
    {
      /* Use the rightmost bit */
      if(Value & 1)
      {
        SET_BIT(BitArray, i + j);
      }
      else
      {
        CLEAR_BIT(BitArray, i + j);
      }
      /* Throw the rightmost bit away, moving the next bit into
position. On the
       * last iteration of the loop, this instruction is pointless.
<shrug>
       */
      Value >>= 1;
    }
  }

int main(void)
{
  unsigned char test_array[9] = {0};

  print_bits(test_array, 9);
  printf("Storing the 19-bit value 0x7FFFF starting at bit 3.\n");
  Put_nBit_Int(test_array, 19, 0, 3, 0x7FFFF);
  print_bits(test_array, 9);
  printf("Retrieving the 19-bit value starting at bit 3: %X\n",
          Get_nBit_Int(test_array, 19, 0, 3));
  printf("Storing the 19-bit value 0x7EDCB "
         "starting at bit 3 + (2 * 19).\n");
  Put_nBit_Int(test_array, 19, 2, 3, 0x7EDCB);
  print_bits(test_array, 9);
  printf("Retrieving the 19-bit value "
         "starting at bit 3 + (2 * 19):%X\n",
         Get_nBit_Int(test_array, 19, 2, 3));

  return 0;

There's nothing terribly shameful about writing non-portable code. I
suspect most of the comp.lang.c regulars write quite a bit of n-p stuff.
The trick is to know what is portable and what is not, and to know how
important portability is (or is not) to your project.

(Of course, in comp.lang.c, we discuss portable code, so if you want
help with non-portable constructs you'll need to seek a
platform-specific newsgroup.)

Also, it's not at all difficult for a compiler to optimize away any
& or % operation that has no effect, because all it has to do is to
compare the operand (255 for &, or 256 for %) with the size of the
type.  It's similar to the very common optimization of substituting
divisions by a power of two with shifting.

More importantly to me, your code would be visually misleading me.  I
imagine the most common application of your technique would be something
like this:

  unsigned long a;
  unsigned char buffer[...];

  buffer[i] = a;
  buffer[i+1] = a >> 8;
  buffer[i+2] = a >> 16;
  buffer[i+3] = a >> 24;

which takes advantage of the assignments naturally chopping off the
unnecessary bits on the "left" side on 8-bit byte platforms.  This
code is not as clear to me as:

  buffer[i] = a & 0xFF;
  buffer[i+1] = (a >> 8) & 0xFF;
  buffer[i+2] = (a >> 16) & 0xFF;
  buffer[i+3] = (a >> 24) & 0xFF;

which is idiomatic - you are extracting bits.  Given that CPU
performance progress continues to outpace I/O performance progress,
does this really slow down your server to a degree that deserves the
adjective "horrible"?

Remember that a lot of non-technical considerations and historical
quirks caused the great similarities in computer architecture you see
today.  If the economics change in the future, it won't be surprising
to see more 24-bit CPUs dedicated to video processing, for example.
The one-billion potential computer users in China all need more than
8 bits for one Chinese character, so if China and other countries
become richer, it won't be surprising that it becomes too expensive to
separately design CPUs with 8-bit bytes for Western use.

I'm not saying you should write all your code assuming China will
become rich.  :)  I'm saying that you could:

  assert(CHAR_BIT == 8);

  1.  The 1% of your users might ship 10,000,000 units of their
      embedded systems, and supply a much larger share of your
      royalties.  (A similar point goes even for free software.)

  2.  A PIC is unlikely to support hosted ISO C in any practical
      way, but there's much more to embedded systems than just
      microcontrollers.

Consider, for instance, gcc's output:

    extern void use(int);

    /* in f0(), mask out unwanted high bits if any, just in case
       CHAR_BIT > 8 */
    void f0(unsigned char *p) {
        use(p[0] & 255);
        use(p[1] & 255);
    }

    /* in f1, just assume CHAR_BIT == 8, or that if CHAR_BIT > 8, no
       unwanted high bits are ever set */
    void f1(unsigned char *p) {
        use(p[0]);
        use(p[1]);
    }

I compiled this with "cc -O2 -mregparm=3 -S" and got this code (plus
of course the usual scaffolding bits, which I deleted):

f0:
        pushl %ebp
        movl %esp,%ebp
        subl $20,%esp
        pushl %ebx
        movl %eax,%ebx
        movzbl (%ebx),%eax
        call use
        movzbl 1(%ebx),%eax
        call use
        popl %ebx
        leave
        ret

f1:
        pushl %ebp
        movl %esp,%ebp
        subl $20,%esp
        pushl %ebx
        movl %eax,%ebx
        movzbl (%ebx),%eax
        call use
        movzbl 1(%ebx),%eax
        call use
        popl %ebx
        leave
        ret

Note that the generated code is absolutely identical in the two
functions.  The "& 255" is redundant because CHAR_BIT is 8 and thus
UCHAR_MAX is 255; so the compiler omitted it.  (This only tests
the "load" case, but I tried the "store" case too and gcc omits
unnecessary masks there as well.)

Note that you can, if you like, test UCHAR_MAX explicitly
as well:

    /* octet() converts an unsigned char to an "octet", i.e., 8 bits */
    #if UCHAR_MAX == 255 /* we know UCHAR_MAX >= 255 */
    #define octet(x) (x) /* if it is exactly 255, it is already 8 bits */
    #else                /* otherwise it must be more bits, so mask */
    #define octet(x) ((x) & 255)
    #endif

...

...

extern unsigned char byte;

void foo(unsigned value)
{
    byte = value;

_foo    PROC NEAR                                       ; COMDAT

; 5    :     byte = value;

  00000 8a 44 24 04      mov     al, BYTE PTR _value$[esp-4]
  00004 a2 00 00 00 00   mov     BYTE PTR _byte, al

; 6    : }

  00009 c3               ret     0
_foo    ENDP

_bar    PROC NEAR                                       ; COMDAT

; 10   :     byte = value & 255;

  00000 8a 44 24 04      mov     al, BYTE PTR _value$[esp-4]
  00004 a2 00 00 00 00   mov     BYTE PTR _byte, al

; 11   : }

  00009 c3               ret     0

I.e. it generates the same code for foo() and bar(). The & 255 operation
has absolutely no overhead here, it is a trivial optimisation for
compilers targetting 8 bit character types to eliminate it.