[fpc-pascal] Return value of StrToHostAddr and StrToHostAddr6 in sockets unit

[Michael Van Canneyt]

On Tue, 12 May 2020, Noel Duffy via fpc-pascal wrote:

> While working with StrToHostAddr and StrToHostAddr6 over the past couple 
> of weeks I've run into issues caused by the functions returning all zero 
> addresses to indicate errors. All-zero addresses are technically valid 
> according to the RFCs, so an all-zero address shouldn't be used as an 
> error sentinel.
>
> E,g:
>
>  0.0.0.0
>  ::
>  ::0.0.0.0
>
> Are considered valid if non-routable addresses. libc's inet_pton will 
> successfully parse these.
>
> A simple solution is to add functions to the sockets unit which accept a 
> var record into which the output will be written and which return a 
> boolean to indicate success or failure. E.g,
>
> function inet_pton4(IP: String; var ip4: in_addr): Boolean;
> function inet_pton6(IP: String; var ip6: in6_addr): Boolean;
>
> The names I use here are the libc names, which many other languages also 
> use.
>
> Now, StrToHostAddr and StrToHostAddr6 can call the appropriate function, 
> and programs that use those functions won't notice any change. But new 
> code will be able to use the new functions and have an unambiguous 
> answer as to whether the address is valid or not.
>
> The change is quite straightforward to make, and it won't break existing 
> code, so I think it's worthwhile to do.
>
> Any thoughts or opinions on this?

I'm all for it, but please use the following names:

function TryStrToHostAddr(IP: String; var ip4: in_addr): Boolean;
function TryStrToHostAddr6(IP: String; var ip6: in6_addr): Boolean;

Rationale for this request: 
All conversion calls in sysutils and dateutils use this naming scheme, 
it's good for consistency.

(and I hate underscores, but that's beside the point ;))

Michael.