After updating to Ubuntu 21.10 which has gcc 11 as its default compiler, sqlite builds show a compiler warning:
I just tried with `sqlite-snapshot-202110132029`:
```
In file included from /usr/include/string.h:519,
from sqlite3.c:13625:
In function ‘memcpy’,
inlined from ‘sqlite3Fts5IndexQuery’ at sqlite3.c:227799:18:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
```
As best I can tell, the compiler is making a guess about the largest possible buffer and the largest possible size passed in to the `memcpy()` call, and complaining about a theoretical problem. Assuming that the surrounding code is allocating the buffer correctly (which it looks like it should be, but I didn't really check), I don't think this is a real problem.
If I constrain nTokens to be less than `UINT32_MAX` (`nToken` is an int, `sqlite3Fts5BufferSize` takes a `u32` size parameter), I get a slightly different warning:
```
In file included from /usr/include/string.h:519,
from sqlite3.c:13625:
In function ‘memcpy’,
inlined from ‘sqlite3Fts5IndexQuery’ at sqlite3.c:227798:18:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Checking that the destination is not `NULL` first seems to make that warning disappear.
This patch shows what I needed to do to make the compiler stop emitting warnings, but I don't think this is suitable for inclusion as-is. I don't feel that I have a strong enough understanding of the surrounding code to create the actual correct patch. I strongly suspect the extra conditions I added are impossible to trigger.
```diff
--- sqlite-snapshot-202110132029/sqlite3.c 2021-10-14 11:46:05.000000000 -0400
+++ sqlite-snapshot-202110132029.new/sqlite3.c 2021-10-28 11:25:49.637791053 -0400
@@ -227793,10 +227793,10 @@ static int sqlite3Fts5IndexQuery(
/* If the QUERY_SCAN flag is set, all other flags must be clear. */
assert( (flags & FTS5INDEX_QUERY_SCAN)==0 || flags==FTS5INDEX_QUERY_SCAN );
- if( sqlite3Fts5BufferSize(&p->rc, &buf, nToken+1)==0 ){
+ if( nToken < UINT32_MAX && sqlite3Fts5BufferSize(&p->rc, &buf, nToken+1)==0 ){
int iIdx = 0; /* Index to search */
int iPrefixIdx = 0; /* +1 prefix index */
- if( nToken ) memcpy(&buf.p[1], pToken, nToken);
+ if( nToken && buf.p != NULL ) memcpy(&buf.p[1], pToken, nToken);
/* Figure out which index to search and set iIdx accordingly. If this
** is a prefix query for which there is no prefix index, set iIdx to
```