Re: [TUHS] conventions around zero padding in ip4

[Ralph Corderoy <ralph@inputplus.co.uk>]

Hi Steffen,

> > It has been standardised; see inet_addr(3p) where ‘p’ means the
> > POSIX version of the man page or
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
> > 
> > Briefly, the string must be one of
> > 
> >     a.b.c.d
> >     a.b.cd
> >     a.bcd
> >     abcd
...
> "However", RFC 2553 says
>
>   RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
>
>      The address conversion functions -- inet_ntoa() and inet_addr() --
>      convert IPv4 addresses between binary and printable form.  These
>      functions are quite specific to 32-bit IPv4 addresses.  We have
>      designed two analogous functions that convert both IPv4 and IPv6
>      addresses

So that RFC added inet_pton(3) and inet_ntop(3).

> And for this POSIX says
>
>   If the af argument of inet_pton( ) is AF_INET, the src string
>   shall be in the standard IPv4 dotted-decimal form:
>   ddd.ddd.ddd.ddd where "ddd" is a one to three digit decimal
>   number between 0 and 255 (see inet_addr( )). The inet_pton()
>   function does not accept other formats [.]

True.  The non-POSIX inet_pton(3) here points out it only accepts IPv4
in decimal 3.1.4.1 form and pushes the programmer to getaddrinfo(3)
instead.

    NOTES

    Unlike inet_aton(3) and inet_addr(3), inet_pton() supports IPv6
    addresses.  On the other hand, inet_pton() accepts only IPv4 addresses
    in dotted-decimal notation, whereas inet_aton(3) and inet_addr(3)
    allow the more general numbers-and-dots notation (hexadecimal and
    octal number formats, and formats that don't require all four bytes
    to be explicitly written).  For an interface that handles both
    IPv6 addresses, and IPv4 addresses in numbers-and-dots notation,
    see getaddrinfo(3).

And POSIX's getaddrinfo(3p) punts to inet_addr(3p) for describing what
IPv4 formats are accepted, so we've gone full circle.

    If the specified address family is AF_INET or AF_UNSPEC, address
    strings using Internet standard dot notation as specified in
    inet_addr() are valid.

It looks to me that the RFC introduced a limited format which then had
to be standardised but the older interface is still being spread by
newer functions like getaddrinfo().

-- 
Cheers, Ralph.