Fix -Wsign-compare on arm32

[kinkie]

Due to ssize_t differences on 32/64 bit platforms, changes
to peerDigestSwapInMask in commit 556b91a cause
signedness comparison errors.
Refactor to be safe both on 32- and 64-bit platforms

[kinkie]

Error message on gentoo/arm7l

src/peer_digest.cc: In function 'int peerDigestSwapInMask(void*, char*, ssize_t)':
src/peer_digest.cc:562:35: error: comparison of integer expressions of different signedness: 'uint32_t' {aka 'unsigned int'} and 'ssize_t' {aka 'int'} [-Werror=sign-compare]
  562 |     if (fetch->mask_offset + size > static_cast<ssize_t>(pd->cd->mask_size)) {
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

see https://github.com/kinkie/dockerfiles/actions/runs/26706938522/job/78709886696

[rousskov]

Thank you for fixing this regression!

src/peer_digest.cc:562:35: error: comparison of integer expressions of different signedness: 'uint32_t' {aka 'unsigned int'} and 'ssize_t' {aka 'int'} [-Werror=sign-compare]

Refactor ... for 32-bit safety ... Due to ssize_t differences on 32/64 bit platforms ...

The jump from "expressions of different signedness" in the error message to "32-bit safety" feels unnecessary here because signedness is different on both 32- and 64-bit platforms AFAICT.

I suggest using something like this for the PR title: Fix -Wsign-compare on arm32.

Please mention the problematic commit SHA in the PR description (or title).

See 4efdc65 for an example.

[rousskov]

Please do not cast a ssize_t variable to a usually smaller and strangely-precise uint32_t. Cast it to size_t.

The assertion we added above the if statement makes a size_t cast safe. Technically, it does not make the proposed uint32_t cast safe (although it is safe for other reasons).

Suggested change

	if (static_cast<uint32_t>(size) > pd->cd->mask_size - fetch->mask_offset) {
	if (static_cast<size_t>(size) > pd->cd->mask_size - fetch->mask_offset) {

The change from summation to subtraction is outside this PR scope, but I am not going to object to it because subtraction is slightly better here (than what was originally done in the problematic commit) -- it avoids a suspicion of overflow. I trust you have verified that subtracting is safe here (i.e. that the right hand side expression cannot underflow).

[kinkie]

I trust you have verified that subtracting is safe here (i.e. that the right hand side expression cannot underflow).

I have and it looks safe, but if we want to be extra safe we can Assure on it, what do you think?

[rousskov]

if we want to be extra safe we can Assure on it, what do you think?

Your call, but I think an Assure would be a good idea here.

[kinkie]

Adding it. It won't hurt and it may help

[kinkie]

@yadij would you mind fast tracking this PR? It's the only blocker I have for releasing 7.6