[TUHS] conventions around zero padding in ip4
Ralph Corderoy
ralph at inputplus.co.uk
Tue May 10 20:49:03 AEST 2022
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.
More information about the TUHS
mailing list