conncache: don't assume curl_off_t increment wrap-around

In the totally unlikely event that next_easy_id would ever wrap, avoid
undefined behavior. It is a signed type.

Also: update the related comment in urldata.h that mentioned LONG_MAX
but is nowadays CURL_OFF_T_MAX

Closes #22569
This commit is contained in:
Daniel Stenberg 2026-08-13 11:34:42 +02:00
parent 9d034539ec
commit ca26e728a6
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
2 changed files with 4 additions and 4 deletions

View file

@ -274,7 +274,7 @@ void Curl_cpool_xfer_init(struct Curl_easy *data)
CPOOL_LOCK(cpool, data);
/* the identifier inside the connection cache */
data->id = cpool->next_easy_id++;
if(cpool->next_easy_id <= 0)
if(cpool->next_easy_id == CURL_OFF_T_MAX)
cpool->next_easy_id = 0;
data->state.lastconnect_id = -1;

View file

@ -1216,9 +1216,9 @@ struct Curl_easy {
/* once an easy handle is tied to a connection pool a non-negative number to
distinguish this transfer from other using the same pool. For easier
tracking in log output. This may wrap around after LONG_MAX to 0 again,
so it has no uniqueness guarantee for large processings. Note: it has no
uniqueness either IFF more than one connection pool is used by the
tracking in log output. This may wrap around after CURL_OFF_T_MAX to 0
again, so it has no uniqueness guarantee for large processings. Note: it
has no uniqueness either IFF more than one connection pool is used by the
libcurl application. */
curl_off_t id;
uint32_t master_mid; /* if set, this transfer belongs to a master */