Am I stupid or is what webmunkey describing similar to what
my book calls a Q(queue).
You have an array and then there are a number of rules
describing how data may enter and leave and what may and
may not be done.
I thought it was a common programming exercise and that it
also mimicks the real stack in memory, assemblers, correct
me if I''m wrong.
Of course, a linked list will work, but since you started
out with an array you may want to keep an index number in
each node.

int array[X] = {1,2,3};
for(i=0;i<(X-1);i++){
array = array[i+1];
}
array=0;<br>/* final result array[X] = {2,3,0} */ </i>

BeerNutts - memcpy will screw you over if the start of the destination lies inside the source block. But for sliding data down an array, the start of the destination lies outside that block, so you''re safe to use it for that purpose. Try it out for yourself and see.

Beer Hunter (BTW, nice name)

I'm not sure of the implementation of memcpy vs memmove in the standard libraries, but considering memmove is described as: "same as memcpy, except it works when objects overlap." would lead me to always use memove if two objects overlapped, regardless of destination or source start.

I guess I'm just conservative, but, for embedded systems, better safe than sorry.

Nutts

Edit:
I actually looked at the old code that caused the problem, and it is exactly like the above problem. I believe it was intermittent, but memcpy was the culprit. We changed this piece of code:

memcpy( &gTaskList[i], &gTaskList[i+1], sizeof( tTaskEntry ) * gulNumTasks - 1 );

to this

memmove( &gTaskList[i], &gTaskList[i+1], sizeof( tTaskEntry ) * gulNumTasks - 1 );

Anyway, you just got me thinking. BTW, all rights reserved on the code above

Nutts

Edited by - BeerNutts on August 6, 2001 3:48:55 PM [/source]

Edited by - BeerNutts on August 6, 2001 3:50:19 PM