The puzzle

unsigned char xdata * data fetch_ptr;
unsigned char xdata * data in_ptr;

part of the ISR
if (RI)
{
*in_ptr = SBUF;
in_ptr++;

part of the main
while (in_ptr > fetch_ptr)
{
my_byte = *fetch_ptr;
fetch_ptr++;

What is wrong [in the code/logic, NOT in the syntax (which may be wrong)]. The pointers ARE initialized etc, the fix for the problem will attach to the lines shown.

part of the main
while (in_ptr > fetch_ptr)
{
my_byte = *fetch_ptr;
fetch_ptr++;
...
}

while (in_ptr > fetch_ptr)

The answer
The C compiler can implement this in many ways, the problem will always be one of the two below.

CASE 1
For illustration I choose the following implementation (pseudo code)

mov r6,HIGH in=ptr
mov r7,LOW  in=ptr
while (r6/r7 > fetch-ptr)
...

Now	as an example      in-ptr R6 R7
mov r6,HIGH in=ptr         2ff     2 --
interrupt happen here
mov r7,LOW  in=ptr	   300     2 00

This, of course would make the while not execute for this byte, but the byte would be caught "next time around"

So, if someone answered "there is no problem" that would be correct.
However, while that would be OK in this case, it is a bad coding practice since all >8bit entities accessed in both an ISR and the main code should be treated as non-atomic..

CASE 2
For illustration I choose the following implementation (pseudo code)

mov r7,LOW  in=ptr
mov r6,HIGH in=ptr
while (r6/r7 > fetch-ptr)
...

Now	as an example      in-ptr R6 R7
mov r7,LOW  in=ptr	   2ff    -- ff
interrupt happen here
mov r6,HIGH in=ptr         300     3 ff

This would cause the main to load 255 bytes when only one was available OOPS

Now, if we made in_ptr volatile the while would execute for this byte, but the "counter error" would be caught "next time around". work this out

So, if someone answered "volatile is required" that would be correct. However, while that would be OK in this case, it is a bad coding practice since all >8bit entities accessed in both an ISR and the main code should be treated as non-atomic..



SOLUTIONS
now, someone would solve it this way

ES = 0;
while (in_ptr > fetch_ptr)
{
  my_byte = *fetch_ptr;
  fetch_ptr++;
  ...
}
ES = 1;

While that, indeed solves the problem it creates 2 new problems

1) what if ES were already disabled? the above would enable it
2) there is a possibility that ES may be disabled a long time

so

Helper_bit = ES;
ES = 0;
Helper_short = in_ptr;
ES = Helper_bit;
while (Helper_short > fetch_ptr)
{
  my_byte = *fetch_ptr;
  fetch_ptr++;
  ...
}

This MAY leave a byte till next main loop - usually not a problem, if it is a problem the following will be required

Helper_bit = ES;
ES = 0;
Helper_short = in_ptr;
ES = Helper_bit;
while (Helper_short > fetch_ptr)
{
  my_byte = *fetch_ptr;
  fetch_ptr++;
  ...
  Helper_bit = ES;
  ES = 0;
  Helper_short = in_ptr;
  ES = Helper_bit;
}

So, as you see a "solution" is one thing, using good coding practices is "safe" and will aways work. Trying to figure out which non-atomic fetches can be done without disabling the interrupt is error prone, as you see above, one case could "cneek by"

SO, if anything more than a byte is operated both in the main and an ISR, that interrupt must be disabled while the main does the store or fetch.

hope it was fun,

Erik