mirror of
https://github.com/curl/curl.git
synced 2026-08-25 11:53:36 +03:00
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:
parent
9d034539ec
commit
ca26e728a6
2 changed files with 4 additions and 4 deletions
|
|
@ -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;
|
||||
|
||||
|
|
|
|||
|
|
@ -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 */
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue