Or should I rather validate port directly in addpeeraddress() and just ignore the -0 case?

I think it can be ignored. Tried using -0 in few other arguments for other RPC and it is considered as 0. I could not find a way to read peers.dat however this observation is based on usage of negative zero in other parameters.

Based on reading few posts like https://softwareengineering.stackexchange.com/questions/280648/why-is-negative-zero-important it could be an issue in some cases but not here I guess.I have no opinion on this because I couldn't do anything interesting with -0 in addpeeraddress

@amadeuszpawlik I tried using port -0 in addnode and it adds negative zero in the port, I am assuming similar thing would happen with addpeeraddress so:

Concept ACK for this PR and maybe we need to make changes for few other RPC

@prayank23 good find with addnode (although in that particular command the port is specified in an address string, so this wouldn't fix it). It looks like -0 is not the only case that addnode accepts.
The modded SplitHostPort I propose in #22087 would definitely be nice here for port validation.
I'll go trough other RPCs and add validation for them too.

My question still stands, is modifying univalue a valid approach for commands that currently use int for port value, or do I ignore the -0 case and simply validate directly in net.cpp?

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.