9 ms·

The problem was (and remained) programmers thinking addresses are strings.

alanfranzoni 8y ago
This. The proper approach is to normalize/deduplicate on ip objects that understand ipv6 domain logic. Then most issues just go away.
jsjohnst 8y ago
I actually prefer them as integers personally. 4 bytes for IPv4, 16 bytes for IPv6, is more space efficient than any string representation usually.
- rkeene2 8y ago
  16 bytes isn't always enough to store an IPv6 address. Depending on the requirements, you may need to store a fully scoped IPv6 address, such as fe80::1%eth0. Edit to note: I store the fully scoped IPv6 address in a database as part of my CMDB mechanism.
  - jsjohnst 8y ago
    Just curious, but what use do you have for storing link-local addresses?
ztorkelson 8y ago
Right. I was waiting for the author to get to this point, and much to my surprise they never did. The takeaway shouldn’t be “strings are hard”. Strings are hard, but that’s not the problem here. The problem is using inappropriate data types for the task at hand, and the takeaway should be that representation matters. Representing an IP endpoint as a string only really makes sense at the human-computer interface. In general, the first thing a program should do with such a string is convert it into a more suitable data type. And as noted elsewhere, more often than not there will already be a library function to do so. Strings are especially pernicious because they are ubiquitous, in that just about anything can be represented as a string, but the operations one can do on a string representation of an object do not generally correspond with the operations one would want to do on the object itself. This disparity is the source of many bugs, which the article exemplifies (though falls short of directly addressing). Similarly problematic are assumptions that converting an object to a string and a string to an object (i.e. `parse` and `format` functions) are bijective. This is not generally the case. (Wise practitioners might choose such a mapping, though, when the opportunity presents.)
- deleted 8y ago
  [deleted]
rhacker 8y ago
They are strings, sometimes, and that is what this article is about. Another non-obvious fix to this issue is to start using DNS. (Well obvious to some)

This. The proper approach is to normalize/deduplicate on ip objects that understand ipv6 domain logic. Then most issues just go away.

jsjohnst 8y ago

I actually prefer them as integers personally. 4 bytes for IPv4, 16 bytes for IPv6, is more space efficient than any string representation usually.

rkeene2 8y ago
16 bytes isn't always enough to store an IPv6 address. Depending on the requirements, you may need to store a fully scoped IPv6 address, such as fe80::1%eth0. Edit to note: I store the fully scoped IPv6 address in a database as part of my CMDB mechanism.
- jsjohnst 8y ago
  Just curious, but what use do you have for storing link-local addresses?

ztorkelson 8y ago

Right. I was waiting for the author to get to this point, and much to my surprise they never did. The takeaway shouldn’t be “strings are hard”. Strings are hard, but that’s not the problem here. The problem is using inappropriate data types for the task at hand, and the takeaway should be that representation matters. Representing an IP endpoint as a string only really makes sense at the human-computer interface. In general, the first thing a program should do with such a string is convert it into a more suitable data type. And as noted elsewhere, more often than not there will already be a library function to do so. Strings are especially pernicious because they are ubiquitous, in that just about anything can be represented as a string, but the operations one can do on a string representation of an object do not generally correspond with the operations one would want to do on the object itself. This disparity is the source of many bugs, which the article exemplifies (though falls short of directly addressing). Similarly problematic are assumptions that converting an object to a string and a string to an object (i.e. `parse` and `format` functions) are bijective. This is not generally the case. (Wise practitioners might choose such a mapping, though, when the opportunity presents.)

deleted 8y ago
[deleted]

rhacker 8y ago

They are strings, sometimes, and that is what this article is about. Another non-obvious fix to this issue is to start using DNS. (Well obvious to some)