Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000184 [1003.1(2008)/Issue 7] System Interfaces Editorial Error 2009-11-13 10:30 2010-01-07 16:25
Reporter axeld View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
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.
Attached Files

- Relationships

-  Notes
(0000305)
nsitbon (reporter)
2009-11-13 20:46

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.
(0000314)
axeld (reporter)
2009-12-03 09:50

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?
(0000317)
nick (manager)
2009-12-03 16:32

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.
(0000328)
axeld (reporter)
2009-12-11 11:56

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.
(0000370)
msbrown (manager)
2010-01-07 16:25

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.

- Issue History
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 20:47 nsitbon Note Added: 0000306
2009-11-13 20:50 nsitbon Note Deleted: 0000306
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


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