View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000184 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2009-11-13 10:30 | 2010-01-07 16:25 |
| Reporter | axeld | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Error |
| Status | Closed | Resolution | Rejected | ||
| Name | Axel Dörfler | ||||
| Organization | |||||
| User Reference | |||||
| Section | inet_ntop | ||||
| Page Number | 1116 | ||||
| Line Number | 37173-37174 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000184: inet_ntop() vs. RFC 2553 | ||||
| Description | The function prototype for inet_ntop() differs from RFC 2553: the "size" parameter is of type "socklen_t" (the 4th parameter), but is declared as type "size_t" in RFC 2553. Since this parameter describes the size of a character buffer, and is not related to struct sockaddr, I would consider this an incorrect change from the original intention. | ||||
| Desired Action | Change the type of the 4th parameter to size_t in subsequent releases. | ||||
| Tags | No tags attached. | ||||
|
|
RFC 2553 is obsoleted by RFC 3493 in which inet_ntop() is declared like this: const char *inet_ntop(int, const void *, char *, socklen_t); so it seems the prototype is good. |
|
|
Still, I can't follow this change of parameter type. "libbind" has not adopted it either, btw, and consistently uses size_t in these use cases. Maybe asking one of the authors of the RFC to know the intention of changing the type to clarify the issue? |
|
|
Austin/50r1 contains XSH ERN 296, where this change was proposed before, and rejected. Action Item 2000-05-022: Andrew Gollan (XSHd3 ERN 296) to forward socklen_t info to IETF WG for inclusion in RFC 2553 replacement (IPv6 API) when published probably explains why the RFC was updated. There is, however, little rationale for the rejection of ERN 296. |
|
|
Sorry for reopening, but it looks like I am not allowed to add a note otherwise. Could you be so kind to explain why this item has been rejected, and why the change to the RFC was suggested in the first place? I can hardly see the rationale behind it. |
|
|
The point for our WG's resolution of "rejected", is that RFC 2553 was superceded by RFC 3493, and that the Issue 7 Specification matches RFC 3493. It is one of our guiding principles that we align with existing standards in a given area whenever possible, and RFC 3493 is the current document for this topic. As for the reasoning behind RFC 3493, please see those documents or the IETF. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-11-13 10:30 | axeld | New Issue | |
| 2009-11-13 10:30 | axeld | Status | New => Under Review |
| 2009-11-13 10:30 | axeld | Assigned To | => ajosey |
| 2009-11-13 10:30 | axeld | Name | => Axel Dörfler |
| 2009-11-13 10:30 | axeld | Section | => inet_ntop |
| 2009-11-13 10:30 | axeld | Page Number | => (page or range of pages) |
| 2009-11-13 10:30 | axeld | Line Number | => (Line or range of lines) |
| 2009-11-13 20:46 | nsitbon | Note Added: 0000305 | |
| 2009-11-13 21:03 | Don Cragun | Page Number | (page or range of pages) => 1116 |
| 2009-11-13 21:03 | Don Cragun | Line Number | (Line or range of lines) => 37173-37174 |
| 2009-11-13 21:03 | Don Cragun | Interp Status | => --- |
| 2009-12-03 09:50 | axeld | Note Added: 0000314 | |
| 2009-12-03 16:32 | nick | Note Added: 0000317 | |
| 2009-12-03 16:35 | msbrown | Status | Under Review => Closed |
| 2009-12-03 16:35 | msbrown | Resolution | Open => Rejected |
| 2009-12-11 11:56 | axeld | Note Added: 0000328 | |
| 2009-12-11 11:56 | axeld | Status | Closed => Under Review |
| 2009-12-11 11:56 | axeld | Resolution | Rejected => Reopened |
| 2010-01-07 16:25 | msbrown | Note Added: 0000370 | |
| 2010-01-07 16:25 | msbrown | Status | Under Review => Closed |
| 2010-01-07 16:25 | msbrown | Resolution | Reopened => Rejected |
