mirror of
https://github.com/haproxy/haproxy.git
synced 2026-05-27 11:52:34 -04:00
CLEANUP: resolvers: use read_n32() instead of open-coded big-endian read
In resolv_validate_dns_response(), the second DNS record parsing path manually constructs a 32-bit big-endian TTL value from four individual bytes using the expression: reader[0] * 16777216 + reader[1] * 65536 + reader[2] * 256 + reader[3] We have read_n32() to do this, and it's more robust against unexpected signedness surprises (which should not happen right here since reader is unsigned char and we use -fwrapv so the result is defined). Also, let's make the ttl an uint instead of an int. The TTL is only retrieved and not used for now, so better clean it now.
This commit is contained in:
parent
4db85fc53e
commit
34f280b66c
2 changed files with 3 additions and 5 deletions
|
|
@ -114,7 +114,7 @@ struct resolv_answer_item {
|
|||
char name[DNS_MAX_NAME_SIZE+1]; /* answer name */
|
||||
int16_t type; /* question type */
|
||||
int16_t class; /* query class */
|
||||
int32_t ttl; /* response TTL */
|
||||
uint32_t ttl; /* response TTL */
|
||||
int16_t priority; /* SRV type priority */
|
||||
uint16_t weight; /* SRV type weight */
|
||||
uint16_t port; /* SRV type port */
|
||||
|
|
|
|||
|
|
@ -1236,8 +1236,7 @@ static int resolv_validate_dns_response(unsigned char *resp, unsigned char *bufe
|
|||
if (reader + 4 > bufend)
|
||||
goto invalid_resp;
|
||||
|
||||
answer_record->ttl = reader[0] * 16777216 + reader[1] * 65536
|
||||
+ reader[2] * 256 + reader[3];
|
||||
answer_record->ttl = read_n32(reader);
|
||||
reader += 4;
|
||||
|
||||
/* Now reading data len */
|
||||
|
|
@ -1498,8 +1497,7 @@ static int resolv_validate_dns_response(unsigned char *resp, unsigned char *bufe
|
|||
if (reader + 4 > bufend)
|
||||
goto invalid_resp;
|
||||
|
||||
answer_record->ttl = reader[0] * 16777216 + reader[1] * 65536
|
||||
+ reader[2] * 256 + reader[3];
|
||||
answer_record->ttl = read_n32(reader);
|
||||
reader += 4;
|
||||
|
||||
/* Now reading data len */
|
||||
|
|
|
|||
Loading…
Reference in a new issue