Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001102 [1003.1(2016)/Issue7+TC2] Base Definitions and Headers Editorial Enhancement Request 2016-11-16 20:07 2020-04-21 14:01
Reporter EdSchouten View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Ed Schouten
Organization Nuxi
User Reference
Section arpa/inet.h
Page Number -
Line Number -
Interp Status ---
Final Accepted Text Note: 0004011
Summary 0001102: inet_addr() cannot parse 255.255.255.255. Mark it as obsolete, add inet_aton(), or both?
Description The inet_addr() function in <arpa/inet.h> can be used to convert a string representation of an IPv4 address to an in_addr_t. In addition to just parsing addresses in dot-decimal form, like inet_pton(), it also accepts alternative forms (hexadecimal, octal, fewer than four parts).

One of the problems with the inet_addr() function is that it cannot parse the address 255.255.255.255, as the function would then return the same value as returned upon failure. (Almost?) all POSIX-like systems have solved this by adding another function that returns the address and success/failure separately:

int inet_aton(const char *, struct in_addr *);

Because this function is not part of POSIX, many pieces of software that need this functionality have added explicit CMake/Autoconf checks, only making use of inet_aton() when present. CPython is an example of such a project. It would be nice if we could eliminate the need for this.
Desired Action We could consider marking inet_addr() obsolete, just like what I'm proposing in bug #1101 for inet_ntoa(). This would, however, cause some new issues:

- We remove an actual feature. We will no longer provide a separate utility function for parsing IPv4 addresses that are not in dot-decimal form. I would argue that this is not a serious problem, as most people nowadays are unaware that such alternative representations even exist.

- The definition of getaddrinfo() currently depends on inet_addr(), as that function must accept IPv4 addresses in that form as well.

This is why I personally think it would make sense to at least add inet_aton(). I'm leaving whether or not inet_addr() should be marked obsolete afterwards open for discussion.

----------------------------------------------------------------------
In article http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/arpa_inet.h.html: [^]

- Add the following prototype:

int inet_aton(const char *, struct in_addr *);

In article http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html: [^]

- Add the following prototype:

int inet_aton(const char *cp, struct in_addr *in);

- Add the following sentence to the description:

"The inet_aton() function is identical to inet_addr(), except that it stores the Internet address in the structure pointed to by 'in'."

- Add the following sentence to the return value:

"Upon successful completion, inet_aton() shall return 1. Otherwise, it shall return 0."

In article http://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html: [^]

- Replace any occurrence of inet_addr() with inet_aton().
----------------------------------------------------------------------
Tags issue8
Attached Files

- Relationships
related to 0001101Appliedajosey inet_ntoa(): superfluous and not thread-safe. Mark as [OB] for issue 8? 

-  Notes
(0003500)
shware_systems (reporter)
2016-11-22 20:43
edited on: 2018-04-19 15:54

All addresses 224.0.0.0 to 255.255.255.255 are part of the reserved but never defined "extending addressing mode" of IPv4 [RFC791,3.2], and 0 is similarly restricted. While an RFC should have been filed as an update to RFC792 that announced this particular usage of 255.255.255.255 as a failure indicator, it has no particular effect on numbers representing hosts with officially assigned addresses, which will have at most 223.x.x.x (or 0xDFFFFFFF in a no dot form) as address.

Still, these are imho a candidate for setting errno, with the usual 'clear errno first' caveat, to EINVAL or EADDRNOTAVAIL as defined 'may fail' errors. Passing -1 could be a 'shall fail' one, possibly, if an RFC does get filed. If that isn't desired the other interface as an alternative seems plausible. As an *_r() type version it's a candidate anyways for Issue 8, I'd think.

Suggested alternate action, without modifying ERRORS section:
----------------------------------------------------------------------
After C165.pdf, Pg 222, Line 7483, add the following prototype:

  int inet_aton(const char *, struct in_addr *);

After Pg 1137, Line 38405 add the following prototype:

  int inet_aton(const char *cp, struct in_addr *in);

After Line 38409 add the following paragraph to the Description:

"The inet_aton() function is identical to inet_addr(), except that it stores the Internet address in the structure pointed to by 'in'. For both it is implementation-defined if a string representing a non-assignable in_addr value is converted or represented as {255,255,255,255}."

After Line 34832 add the following paragraph to the Return Value:

"Upon successful completion, inet_aton() shall return 1. Otherwise, it shall return 0."

After Pg1138, Line 38441, add the following paragraph:
As a first byte of 0 or in the range 224 to 255 are not considered valid IPv4 addresses for assignments to computers on the internet, these interfaces should report failure when presented a string or in_addr value specifying such a first byte. A platform may use some of these values in support of implementation-defined features so this is not a requirement except for the reserved value of (in_addr){255,255,255,255}, as the failure indicator for inet_addr(). Portable applications shall ensure the values used are in the assignable range for the function used for consistent results.
----------------------------------------------------------------------

(0003501)
kre (reporter)
2016-11-22 23:20

Sorry, but note 3500 is utter nonsense.

There neither is, nor ever has been, any expectation that the inet_*()
functions should only apply to IP addresses that can be assigned to hosts.

They apply to any IP (IPv4 only for some of them) address, including,
in particular, the local net broadcast address (255.255.255.255). They
can also be (and also are in practice) used with values that aren't addresses
but are netmasks (and so commonly start 255....)

The ambiguity between -1 representing both the error indicator, and the IP
address that is the broadcast addr is unfortunate, in the functions for which
that happens - but they were designed in the time before 255.255.255.255 was
designated for this purpose, and even back when broadcast addresses were
more commonly netnumber.0

Deprecating usage of those functions is a fine idea, as would be (perhaps
slightly less ideal, but maybe practically important) simply noting the
problem and leaving applications to deal with it - but reinventing the
functions to be something different than they ever have been, just to make
the problem appear to vanish is absurd.

kre
(0003502)
shware_systems (reporter)
2016-11-23 07:40

I did not see any RFC amending 792 that officially endorses use of the 0 or 255 first bytes to supersede clause 3.2; vendors stopped using the 0 range because IETF did make a fuss about it being reserved to them at one time. Maybe I missed it, but I did pull up all the amending RFCs listed. That makes the use platform or vendor based extensions, which I make allowance for.

These are also used for mask values, I agree, but any valid mask has zero bits somewhere in it, so 255.255.255.255 is a no-op as an AND netmask, and these don't get put in the source or dest address of a packet to be sent over a socket, the masked values do. The NIC hardware or drivers are expected to convert sentinel values a platform uses, which might look like a mask, to values matching the actual net/host configuration transparently. That's covered in another RFC from the pre-sockets era, but I forget the number.

The expectation stems from the phrasing "to an integer value suitable for use as an Internet address". Illegal addresses are therefore NOT suitable conversion values, to me, even as masks or for special addressing like broadcasts. Those are extensions. So this is an attempt at clarification, not reinvention. For no expectation something along the lines of "to an integer value in network byte order for casting directly to an inaddr_t type." would be more in order, as then it is just format that's a consideration, not eventual usage. Given the RFCs existed well before XNS5, I'm more disposed to thinking the intent of the phrasing was to be compatible with their requirements, however nonsensical they look at first glance.
(0003503)
dannyniu (reporter)
2016-11-24 14:43

Does this mean we'll have to deprecate atoi(3) as well? Programmers' gonna loose quite a lot of convenience be cause they have to write '192.168.1.2' as 0xC0A80102. I don't think it's not common place for some very small programs to do something "ad hoc" like this:

int main(int ac, char *av[]) { return atoi(av[1]); }
(0004011)
geoffclare (manager)
2018-04-26 15:11

After applying the changes from 0001101, apply the following changes:

On page 934 line 31730-31731 (getaddrinfo() DESCRIPTION) change:
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
to:
If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_pton( ) are valid.

On page 1137 lines 38404-38406 (inet_addr(), inet_ntoa() SYNOPSIS), mark the entire SYNOPSIS obsolescent and on the remainder of the page remove the other OB shading that was added by 0001101.

On page 1138 after line 38441 but before the new paragraph added from 0001101, insert a new paragraph:
Applications should prefer inet_pton( ) over inet_addr( ) for the following reasons:

  • The return value from inet_addr( ) when converting 255.255.255.255 is indistinguisable from an error.

  • The inet_pton( ) function supports multiple address families.

  • The alternative textual representations supported by inet_addr( ) (but not by inet_pton( )) are often used maliciously to confuse or mislead users (e.g., for phishing).


On page 1138 line 38445 replace the FUTURE DIRECTIONS section with:
These functions are included only for compatibility with older implementations and may be removed in a future version.

On page 1139 line 38478 (inet_pton() DESCRIPTION) delete:
(see inet_addr( ))

- Issue History
Date Modified Username Field Change
2016-11-16 20:07 EdSchouten New Issue
2016-11-16 20:07 EdSchouten Status New => Under Review
2016-11-16 20:07 EdSchouten Assigned To => ajosey
2016-11-16 20:07 EdSchouten Name => Ed Schouten
2016-11-16 20:07 EdSchouten Organization => Nuxi
2016-11-16 20:07 EdSchouten Section => arpa/inet.h
2016-11-16 20:07 EdSchouten Page Number => -
2016-11-16 20:07 EdSchouten Line Number => -
2016-11-22 20:43 shware_systems Note Added: 0003500
2016-11-22 23:20 kre Note Added: 0003501
2016-11-23 07:40 shware_systems Note Added: 0003502
2016-11-24 14:43 dannyniu Note Added: 0003503
2016-12-08 15:25 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016)/Issue7+TC2
2018-04-19 15:54 shware_systems Note Edited: 0003500
2018-04-19 16:14 geoffclare Relationship added related to 0001101
2018-04-26 15:11 geoffclare Note Added: 0004011
2018-04-26 15:12 geoffclare Interp Status => ---
2018-04-26 15:12 geoffclare Final Accepted Text => Note: 0004011
2018-04-26 15:12 geoffclare Status Under Review => Resolved
2018-04-26 15:12 geoffclare Resolution Open => Accepted As Marked
2018-04-26 15:13 geoffclare Tag Attached: issue8
2020-04-21 14:01 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker