fix: Don't use memcmp to compare IP_Ports.

[iphydf]

memcmp compares padding bytes as well, which may be arbitrary or uninitialised.

---

This change is 

[codecov]

Codecov Report

Attention: 13 lines in your changes are missing coverage. Please review.

Comparison is base (d94246a) 73.72% compared to head (39aadf8) 73.60%.

Files	Patch %	Lines
toxcore/network.c	61.76%	13 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2605      +/-   ##
==========================================
- Coverage   73.72%   73.60%   -0.13%     
==========================================
  Files         148      148              
  Lines       30369    30407      +38     
==========================================
- Hits        22390    22380      -10     
- Misses       7979     8027      +48     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JFreegman]

Reviewed 8 of 8 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @iphydf)

---

toxcore/network.h line 365 at r1 (raw file):

 */
non_null()
int ipport_cmp_handler(const void *a, const void *b, size_t size);

What do the return values indicate?

---

toxcore/network.c line 1460 at r1 (raw file):

    }
    // If family isn't ipv4, assume ipv6 and compare as many bytes as we can.
    return ip6_cmp(&a->ip.v6, &b->ip.v6);

Why do we assume it's ip6 here when there are more than two possibilities?

[nurupo]

Reviewed 1 of 8 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: 2 change requests, 0 of 1 approvals obtained (waiting on @iphydf)

---

toxcore/network.c line 1441 at r2 (raw file):

static int ip4_cmp(const IP4 *a, const IP4 *b)
{
    return a->uint32 - b->uint32;

Can't this value overflow the return type of int? Even if int is 32-bit, since it's signed, it has half the range of uint32. Maybe return -1, 0, 1 instead?

---

toxcore/network.c line 1448 at r2 (raw file):

{
    if (a->uint64[0] != b->uint64[0]) {
        return a->uint64[0] - b->uint64[0];

Can't this value overflow the return type of int? Maybe return -1, 0, 1 instead?

---

toxcore/network.c line 1450 at r2 (raw file):

        return a->uint64[0] - b->uint64[0];
    }
    return a->uint64[1] - b->uint64[1];

Can't this value overflow the return type of int? Maybe return -1, 0, 1 instead?

[JFreegman]

toxcore/network.c line 1441 at r2 (raw file):

Previously, nurupo wrote…

Can't this value overflow the return type of int? Even is int is 32-bit, since it's signed, it has half the range of uint32. Maybe return -1, 0, 1 instead?

Does an overflow even matter? We only care that the result isn't 0 (I believe?)

[iphydf]

Reviewable status: 2 change requests, 0 of 1 approvals obtained (waiting on @JFreegman and @nurupo)

---

toxcore/network.h line 365 at r1 (raw file):

Previously, JFreegman wrote…

What do the return values indicate?

Added docs for it.

---

toxcore/network.c line 1460 at r1 (raw file):

Previously, JFreegman wrote…

Why do we assume it's ip6 here when there are more than two possibilities?

Meh :). You're right, this is more proper.

---

toxcore/network.c line 1441 at r2 (raw file):

Previously, JFreegman wrote…

Does an overflow even matter? We only care that the result isn't 0 (I believe?)

Doesn't really matter, but fixed anyway.

---

toxcore/network.c line 1448 at r2 (raw file):

Previously, nurupo wrote…

Can't this value overflow the return type of int? Maybe return -1, 0, 1 instead?

Done.

---

toxcore/network.c line 1450 at r2 (raw file):

Previously, nurupo wrote…

Can't this value overflow the return type of int? Maybe return -1, 0, 1 instead?

Done.

[nurupo]

Reviewed 5 of 7 files at r3, 2 of 2 files at r4, all commit messages.
Reviewable status: complete! 1 change requests, 1 of 1 approvals obtained (waiting on @JFreegman)

[JFreegman]

Reviewed 3 of 7 files at r3, 2 of 2 files at r4, 6 of 6 files at r5, all commit messages.
Reviewable status: complete! 2 of 1 approvals obtained