BB>   I don't even see the problem with pointer arithmetic
BB>   but maybe I'm just used to it.
   I've done a bit of playing around with pointer math vs.
   array notation and have found absolutely no differences in
   execution time between them, which implies to me that the
   compiler actually interprets array notations as pointer
   math, which suspicion is borne up also by the oddity by
   which a given array:
int array[100], index;
   yields the same result whether you access it as:
x = index[array];
   or as:
x = array[index];
   In either case, you would get:
x = *(array + index);
   This, taken with the timing tests, seems to indicate that
   array notation is, as one ECHO participant once called it,
   "syntactical sugar", and is merely a method of aliasing
   for pointer math. The one area in which it makes some type
   of difference is exemplified by struct assignment, where you
   can use the array notation directly, but must dereference
   the pointer when using pointer math. The array notation gives
   us the object itself, but the pointer math gives us a pointer
   to the object. In one instance, I used two pointers to a
   struct with 64,000 bytes arranged in a two dimensional array
   of type unsigned char, like so:
typedef struct { unsigned char V[200][320]; } VIDMEM;
VIDMEM *ScreenBuf = malloc(sizeof(VIDMEM));
VIDMEM *ScreenMen = (VIDMEM*)0xa0000000L;
   I became a bit frustrated by being unable to use struct
   assignment in place of memcopy() because I was not
   dereferencing my pointers, and finally stumbled across the
   idea to use
ScreenMem[0] = ScreenBuf[0];
   which could just as well, had I been aware of it, written as:
*ScreenMem = *ScreenBuf;
   Ah... The innocence of youth... 

> ] A one-eyed man among the blind is a dangerous heretic.......

---