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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
