File: src/bacnet/basic/binding/address.c

While debugging the ReadRange service, I found that the function rr_address_list_encode() is not working correctly.
In my test (see attached test1.jpg),
the device has 1 binding entry, and I requested a ReadRange.

However, although the Item Count is correctly reported as 1, there is no ItemData in the response packet.
After investigation, I found that the following section seems problematic:

    while ((pMatch->Flags & (BAC_ADDR_IN_USE | BAC_ADDR_BIND_REQ)) != BAC_ADDR_IN_USE) {
        /* Find next bound entry */
        pMatch++;
        /* Can normally not happen. */
        if (pMatch > &Address_Cache[MAX_ADDRESS_CACHE - 1]) {
            /* Issue with the table. */
            return (0);
        }
    }

This logic causes the function to return prematurely, even when a valid entry exists at the end of the table.
So I modified it as follows:

  while ((pMatch->Flags & (BAC_ADDR_IN_USE | BAC_ADDR_BIND_REQ)) != BAC_ADDR_IN_USE) {
      /* Find next bound entry */
      pMatch++;
      /* Can normally not happen. */
      if (pMatch > &Address_Cache[MAX_ADDRESS_CACHE - 1]) {
          uiLast = uiTotal;
          break;
      }
  }
  /* Escaping the upper while loop, then set the bitstring */
  if (pMatch > &Address_Cache[MAX_ADDRESS_CACHE - 1]) {
      break;
  }

After this change, the response became normal, and the ItemData was properly encoded.
Even if not exactly in this way,
I believe this section requires a review or adjustment to handle end-of-table conditions properly.