[fpc-pascal] Bugs in StrToHostAddr6 in sockets unit

[Noel Duffy]

On 3/05/20 10:28 pm, Michael Van Canneyt wrote:
> 
> On Sun, 3 May 2020, Noel Duffy via fpc-pascal wrote:
> 
>> On Sun, 3 May 2020 09:57:46 +0200 (CEST) Michael Van Canneyt 
>> <michael at freepascal.org> wrote:
>>>
> Yes, please open a bug report. If you attach a small console test 
> program that
> demonstrates the bug (and subsequently the fix) then I will make sure it
> ends up in the correct place. If you make sure it exits with exit code 0 
> if all is
> well, and a nonzero exit code if there is an error, that will save me some
> work. If you post the URL for the bug here, I will look at it at once.

To follow-up on this issue I raised in bug #37013 
(https://bugs.freepascal.org/view.php?id=37013), I've been digging into 
RFC4291 to see what address formats for IPv6 exist, and I see that the 
scope of this problem is bigger than I envisioned.

To summarize, the current function, StrToHostAddr6, from the sockets 
unit, will successfully parse many address formats expressly forbidden 
by RFC4291, and it fails to parse others that the RFC expressly 
requires. An example of the latter is this ugly form:

fe80:caf1:906e:9d2f:a520:4172:172.16.31.14

This apparently exists to make IPv4 to IPv6 transitions easier.

Anyway, back to the bug report. I can't make StrToHostAddr6 RFC4291 
compliant without rewriting it, and I don't want to undertake that 
unless I know it's something the FPC community actually wants. I am 
happy to do the work, don't get me wrong, but I realise that a wholesale 
  rewrite of the function is much wider in scope and has more potential 
for drawbacks.

Testing would also have to be fairly rigorous to make sure all the 
different formats are handled correctly. I've already done some  work to 
make it easy to compare StrToHostAddr6's output to that of inet_pton in 
the C library, so this would at least provide a good method to quickly 
spot problems.

So I guess the question is, is it worth the effort to make 
StrToHostAddr6 RFC4291 compliant? Is that something the FPC team would 
want, or do they just not use the sockets unit?