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

Michael Van Canneyt michael at freepascal.org
Tue May 12 12:32:53 CEST 2020

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:
>  ::
>  ::
> 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 ;))


More information about the fpc-pascal mailing list