newest glibc , fstrm master ,protobuf master, protobuf-c master, simdzone makes trouble

[osevan]

debian sid with custom compiled glibc path and read title

simdzone/./src/generic/ip6.h: In function ‘inet_pton6’:
simdzone/./src/generic/ip6.h:172:17: warning: writing 32 bytes into a region of size 0 [-Wstringop-overflow=]
  172 |       endp[- i] = colonp[n - i];
      |                 ^
simdzone/./src/generic/ip6.h:102:11: note: at offset [-2147483600, -16] into destination object ‘tmp’ of size 16
  102 |   uint8_t tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;
      |           ^
gcc -I/usr/lib/x86_64-linux-gnu/mylibc/glibc-2.41/install/includ
simdzone/./src/generic/ip6.h: In function ‘inet_pton6’:
simdzone/./src/generic/ip6.h:172:17: warning: writing 32 bytes into a region of size 0 [-Wstringop-overflow=]
  172 |       endp[- i] = colonp[n - i];
      |                 ^
simdzone/./src/generic/ip6.h:102:11: note: at offset [-2147483600, -16] into destination object ‘tmp’ of size 16
  102 |   uint8_t tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;

[wcawijngaards]

This code does not give that warning with gcc-11, or gcc-13 for me. I guess the stringop-overflow check has an issue here. I can not find the cause of the issue. The write moves the data to the end of the buffer, it is a buffer of size 16, 'tmp', and endp is one-past-the-end of that buffer. With i ranging from 1 to n; and n <= 16, I see no problems with the assignment. It is not 32 bytes into the buffer.

Is the string op parser happier with a notation like *(endp - i) ? If so, this change would remove the warning?

diff --git a/src/generic/ip6.h b/src/generic/ip6.h
index 81d9b68..85207ce 100644
--- a/src/generic/ip6.h
+++ b/src/generic/ip6.h
@@ -169,7 +169,7 @@ inet_pton6(const char *src, uint8_t *dst)
     int i;
 
     for (i = 1; i <= n; i++) {
-      endp[- i] = colonp[n - i];
+      *(endp - i) = colonp[n - i];
       colonp[n - i] = 0;
     }
     tp = endp;

Or do you think there is actually an error in the string operation? It looks fine. It may also be possible to write the loop as a memmove call, instead.