Integer to IPv4
Unpack the 32-bit integer into four bytes, most significant first. 3232235777 becomes 192.168.1.1. Anything above 4294967295 is out of range for IPv4.
How to convert an integer to an IP
The unpacking is four shift-and-mask operations: shift right by 24, 16, 8 and 0, masking each with 255. Seeing it written that way makes the structure obvious; the address really is one number, and the octets are just four slices of it.
A negative integer is the commonest reason this refuses an input, and the fix is arithmetic rather than a different tool. Signed 32-bit storage cannot hold anything from 128.0.0.0 upwards, so those addresses come back wrapped: −1062731519 plus 4294967296 is 3232235777, which is 192.168.1.1. Nothing about a negative number says which convention produced it, so it is refused rather than assumed.
Byte order is the other way this goes wrong quietly. Read the slices in the wrong direction and 192.168.1.1 becomes 1.1.168.192. Valid, plausible, and a different machine entirely. Addresses travel over the network big-endian while most processors are little-endian, which is what ntohl and htonl exist to reconcile. If a decoded address looks almost familiar, try reversing the octets before deciding the data is corrupt.
Questions
192.168.1.1.
Add 4294967296. It was stored signed, and a signed 32-bit column cannot hold anything from 128.0.0.0 up.
0 to 4294967295, which is 0.0.0.0 to 255.255.255.255. Both ends are valid integers and neither is a host you can talk to.
Shift right by 24, 16, 8 and 0, masking each result with 255.
It is padded to the full 32 bits, so each octet is exactly two digits. 192.168.1.1 is C0A80101.
MySQL has INET_NTOA for exactly this. PostgreSQL has an inet type that handles the arithmetic itself, so the integer round trip is rarely needed there.
Very much. Reversing it gives a different valid address — 1.1.168.192 rather than 192.168.1.1, which is the classic endianness bug.
Not with a 32-bit integer — IPv6 needs 128 bits.