|Anonymous | Login||2023-12-05 11:48 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001101||[1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers||Editorial||Enhancement Request||2016-11-16 15:58||2020-04-21 14:01|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||See Note: 0003974.|
|Summary||0001101: inet_ntoa(): superfluous and not thread-safe. Mark as [OB] for issue 8?|
Issue 6 added the new functions inet_ntop() and inet_pton() to <arpa/inet.h>, as replacement for the existing functions. The main advantage of these new functions is that they can be used for multiple network protocols, whereas inet_addr() and inet_ntoa() only support IPv4.
Reading the description of inet_ntoa(), it's not entirely clear to me what this function has to offer over inet_ntop(). They both generate a string of the same format. inet_ntoa() does have one really big disadvantage: it's not thread-safe.
Given that software authors nowadays care more strongly about thread-safety than they did in the past, I would hereby like to propose that we mark inet_ntoa() as obsolete. Proposed changes:
In article http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/arpa_inet.h.html: [^]
- Add [OB] markers around the prototype of inet_ntoa().
In article http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html: [^]
- Add [OB] markers around the prototype of inet_ntoa(). Maybe it should also have a blue background colour now?
- Add [OB] markers around the following sentences from the description and return value:
"The inet_ntoa() function shall convert the Internet host address specified by in to a string in the Internet standard dot notation."
"The inet_ntoa() function need not be thread-safe."
"The inet_ntoa() function shall return a pointer to the network address in Internet standard dot notation."
The primary difference that I see is that since inet_addr() accepts the abbreviated input forms of address, it's expected that inet_ntoa() may also return abbreviated output according to arpa's original conventions, pre-DNS-lookup based, when the trailer bits are all zeros so the functions are complementary. At one time allowing this was part of the "Internet standard dot notation" defined by RFCs. The description does not say the abbreviations are still considered legal output strings, however, so it is also reasonable to expect the full 3 period form is all they'll output, confusingly similar to inet_ntop(). I did not see (though I didn't look all THAT hard) last time I looked that these string forms are considered entirely superseded by more current RFC's, for backwards compatibility. They're more legacy than obsolete, but still may be relevant to terminal, or dial-in modem, server systems where the only network connection is directly to the arpa backbone.
For inet_ntop() I see the expectation as it shall always return a string with all the periods, n.n.n.n, to be the complement of inet_pton() requiring this. I believe this became more required for most platforms when local groups, of the 192.168.x.x variety, were added as a range type with implementation-defined prefix and semantics for the following bits that might not match arpa's usages, so can't be truncated.
Don Cragun (manager)
Make the changes suggested in the Desired Action and also make the following changes:
On page 1138 after line 38441 (inet_ntoa() APPLICATION USAGE) insert a new paragraph:
Applications should prefer inet_ntop() over inet_ntoa() as it supports multiple address families and is thread-safe.
On page 1138 line 38445 replace the inet_ntoa() FUTURE DIRECTIONS section with:
The inet_ntoa() function may be removed in a future version.
On page 1138 line 38447 add inet_ntop() to the SEE ALSO section.
|2016-11-16 15:58||EdSchouten||New Issue|
|2016-11-16 15:58||EdSchouten||Status||New => Under Review|
|2016-11-16 15:58||EdSchouten||Assigned To||=> ajosey|
|2016-11-16 15:58||EdSchouten||Name||=> Ed Schouten|
|2016-11-16 15:58||EdSchouten||Organization||=> Nuxi|
|2016-11-16 15:58||EdSchouten||Section||=> arpa/inet.h|
|2016-11-16 15:58||EdSchouten||Page Number||=> -|
|2016-11-16 15:58||EdSchouten||Line Number||=> -|
|2016-11-17 20:20||shware_systems||Note Added: 0003496|
|2016-12-08 15:25||geoffclare||Project||1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2|
|2018-04-19 15:43||Don Cragun||Interp Status||=> ---|
|2018-04-19 15:43||Don Cragun||Note Added: 0003974|
|2018-04-19 15:43||Don Cragun||Status||Under Review => Resolved|
|2018-04-19 15:43||Don Cragun||Resolution||Open => Accepted As Marked|
|2018-04-19 15:43||Don Cragun||Final Accepted Text||=> See Note: 0003974.|
|2018-04-19 15:44||Don Cragun||Tag Attached: issue8|
|2018-04-19 16:14||geoffclare||Relationship added||related to 0001102|
|2020-04-21 14:01||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|