Mac@programming.dev to Programmer Humor@programming.dev · 11 months agoGoOnprogramming.devimagemessage-square88fedilinkarrow-up1968
arrow-up1924imageGoOnprogramming.devMac@programming.dev to Programmer Humor@programming.dev · 11 months agomessage-square88fedilink
minus-squareEmma_Gold_Man@lemmy.dbzer0.comlinkfedilinkarrow-up8·11 months 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-211 months 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·11 months 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