Mac@programming.dev to Programmer Humor@programming.dev · 1 year agoGoOnprogramming.devimagemessage-square88fedilinkarrow-up1968
arrow-up1924imageGoOnprogramming.devMac@programming.dev to Programmer Humor@programming.dev · 1 year agomessage-square88fedilink
minus-squareEmma_Gold_Man@lemmy.dbzer0.comlinkfedilinkarrow-up8·1 year agoAnd dupe check. 0.0.0.0 and 000.000.000.000 may both be valid, but they resolve the same
minus-squareDanny M@lemmy.escapebigtech.infolinkfedilinkarrow-up3·edit-21 year agoDefinitely, tho if you store it as a u32 that is fixed magically. Because 1.2.3.4 and 1.02.003.04 both map to the same number. What I mean by storing it as a u32 is to convert it to a number, similar to how the IP gets sent over the wire, so for v4: octet[3] | octet[2] << 8 | octet[1] << 16 | octet[0] << 24 or in more human terms: (fourth octet) + (third octet * 256) + (second octet * 256^2) + (first octet * 256^3)
minus-squareEmma_Gold_Man@lemmy.dbzer0.comlinkfedilinkarrow-up2·1 year agoTrue enough for database or dictionary storage, but a lot of times things get implemented in arrays where you still wind up with two copies of the same uint32.
And dupe check. 0.0.0.0 and 000.000.000.000 may both be valid, but they resolve the same
Definitely, tho if you store it as a u32 that is fixed magically. Because 1.2.3.4 and 1.02.003.04 both map to the same number.
What I mean by storing it as a u32 is to convert it to a number, similar to how the IP gets sent over the wire, so for v4:
octet[3] | octet[2] << 8 | octet[1] << 16 | octet[0] << 24
or in more human terms:
(fourth octet) + (third octet * 256) + (second octet * 256^2) + (first octet * 256^3)
True enough for database or dictionary storage, but a lot of times things get implemented in arrays where you still wind up with two copies of the same uint32.
deleted by creator