mbedtls: fix build on GCC 14
Without this patch, GCC 14 incorrectly complains about the following error:
In file included from /home/user/workspace/mbedtls/library/ctr_drbg.c:13:
In function ‘mbedtls_xor’,
inlined from ‘ctr_drbg_update_internal’ at /home/user/workspace/mbedtls/library/ctr_drbg.c:372:5:
/home/user/workspace/mbedtls/library/common.h:235:17: error: array subscript 48 is outside array bounds of ‘unsigned char[48]’ [-Werror=array-bounds=]
235 | r[i] = a[i] ^ b[i];
| ~^~~
/home/user/workspace/mbedtls/library/ctr_drbg.c: In function ‘ctr_drbg_update_internal’:
/home/user/workspace/mbedtls/library/ctr_drbg.c:335:19: note: at offset 48 into object ‘tmp’ of size 48
335 | unsigned char tmp[MBEDTLS_CTR_DRBG_SEEDLEN];
| ^~~
In function ‘mbedtls_xor’,
inlined from ‘ctr_drbg_update_internal’ at /home/user/workspace/mbedtls/library/ctr_drbg.c:372:5:
/home/user/workspace/mbedtls/library/common.h:235:24: error: array subscript 48 is outside array bounds of ‘const unsigned char[48]’ [-Werror=array-bounds=]
235 | r[i] = a[i] ^ b[i];
| ~^~~
/home/user/workspace/mbedtls/library/ctr_drbg.c: In function ‘ctr_drbg_update_internal’:
/home/user/workspace/mbedtls/library/ctr_drbg.c:333:57: note: at offset 48 into object ‘data’ of size [0, 48]
333 | const unsigned char data[MBEDTLS_CTR_DRBG_SEEDLEN])
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘mbedtls_xor’,
inlined from ‘ctr_drbg_update_internal’ at /home/user/workspace/mbedtls/library/ctr_drbg.c:372:5:
/home/user/workspace/mbedtls/library/common.h:235:14: error: array subscript 48 is outside array bounds of ‘unsigned char[48]’ [-Werror=array-bounds=]
235 | r[i] = a[i] ^ b[i];
| ~~~~~^~~~~~~~~~~~~
/home/user/workspace/mbedtls/library/ctr_drbg.c: In function ‘ctr_drbg_update_internal’:
/home/user/workspace/mbedtls/library/ctr_drbg.c:335:19: note: at offset 48 into object ‘tmp’ of size 48
335 | unsigned char tmp[MBEDTLS_CTR_DRBG_SEEDLEN];
| ^~~
This change adds a basic check to silence the warning until a solution is worked on upstream.
As this check is already used by another compiler, it shouldn't cause any issues for us.
Signed-off-by: Rany Hany <rany_hany@riseup.net>