System.Net.Socket needs a major code review/rewrite to improve quality and add IPv6 support

I’ve just added a fairly scathing comment to the following issue:

https://quality.embarcadero.com/browse/RSP-17629

Considering that IPv6 has been a ratified standard for over 6 years now and was a draft standard for nearly 20 years prior to that, it’s surprising that there are only 10 votes for this issue. The issue itself is also over 6 years old as well.

I’ve also pointed out a multitude of problems with this unit as justification for it needing a major code review and rewrite.

I think that this issue deserves some more votes to get some attention paid to it so please take a look and cast a vote if you agree.

2 Likes

Agreed, and voted :slight_smile:

1 Like

Voted!
Agree. This is a big hole in Delphi

We all need to push harder to make sure the product is kept up to date and both language features and libraries are up-to-date to keep Delphi alive. A lot of resources have been wasted on the failed .NET Delphi and then the FMX project, and then the ongoing multi-year code insight update failure, at the expense of making sure key libraries like sockets, web server integration & rest, security libraries and common data formats like JSON, XML are supporting all key technologies required.

Just spent a whole day chasing up a bug, where:

Var

S : ansistring;

[…]

S := ;

S := ‘some literal values with ASCII codes’#4#1#6 + FunctionReturningAString(params…) + s + #10#20$30‘more stuff’;

The end result would sometimes be a few bytes shorter than expected. Only under Linux. And in only ~75% of runs: when doing 1000 runs, for instance, the good result count would be somewhere from 730 to 760.

Just splitting this assignment into parts and doing them one by one, with a temporary string in between for temp storage, fixed it. Still no idea why, too hard to debug under Linux – slower and some things cannot be seen.

So my vote would go for this new language feature in Delphi: just get it all working right.

Alex