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
0001101 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Enhancement Request 2016-11-16 15:58 2024-06-11 09:09
Reporter EdSchouten View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Ed Schouten
Organization Nuxi
User Reference
Section arpa/inet.h
Page Number -
Line Number -
Interp Status ---
Final Accepted Text See Note: 0003974.
Summary 0001101: inet_ntoa(): superfluous and not thread-safe. Mark as [OB] for issue 8?
Description 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.
Desired Action 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 [^]

- Add [OB] markers around the prototype of inet_ntoa().

In article [^]

- 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."
Tags issue8
Attached Files

- Relationships
related to 0001102Closedajosey inet_addr() cannot parse Mark it as obsolete, add inet_aton(), or both? 

-  Notes
shware_systems (reporter)
2016-11-17 20:20

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)
2018-04-19 15:43

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.

- Issue History
Date Modified Username Field Change
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
2024-06-11 09:09 agadmin Status Applied => Closed

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