The test code is a simple `fstream.readData(ipa.addr, ipa.sizeoff)` with `ipa` 
being an `IpAddress` and a prior `fstream.write(ipa)`.

The problem seems not to appear in very simple code like write one IP then 
another one and then a third one ... and then read them back just as simply. In 
my real world case though the IP addresses are part of a struct/object with 
other data before and after it. And then I works (well, at least with a small 
number of test entries) if using only IPv4 but breaks when there are mixed IP 
addresses.

My assumption is that there is a problem somewhere deep down in Nims magic.

Reason: Looking at the file created I notice IpAddress (no matter which type) 
are written simply as a family byte (1 for IPv4 and 0 for IPv6) followed by the 
4 or 16 IP address bytes. For strings it's even more magic as there is no 
length written out but just the bytes of the string.

One (as a user) can, of course work around that, e.g. by writing IP addresses 
out as strings (and let Nim's magic take care of it) and reading them back as 
strings too. Another way would be to write the length (in bytes) of the IP 
address somewhere in front of the address bytes. Certainly there are other ways 
too.

This issue has me thinking quite a bit and one of the points I came up with is 
that IMHO using 0 (first elem in family enum) as discriminator for IPv6 (and 1 
for IPv4) might not be the smartest thing to do. It seems to me that using 4 
and 16 (the byte array length of the addresses) would be useful and allow for 
some smart stuff like saving an implicit `if`.

Moreover it would be desirable to have real discriminated structures/objects to 
allow for _one_ ` address` field rather than `address_v4` and `address_v6` 
complicating life elsewhere.

Please note that the problem might be perfectly well on my side. I find myself 
still quite often thinking in C or Ada and quite possibly just didn't get the 
full hang of Nim yet and/or made an error that shows as an IpAddress related 
problem but actually isn't.

I found the problem worthy of mentioning anyway, if only because at the very 
minimum it seems to me that I got bitten by an unlucky combination of still 
very much lacking docs and Nim magic deep down where we users usually don't 
look.

Reply via email to