Anonymous | Login | 2024-11-13 14:23 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000464 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Omission | 2011-06-13 06:59 | 2013-04-16 13:06 | ||
Reporter | markh | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
Name | Mark Harris | ||||||
Organization | |||||||
User Reference | |||||||
Section | accept | ||||||
Page Number | 559 | ||||||
Line Number | 19380 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | |||||||
Summary | 0000464: Inaccurate address_len description in socket functions | ||||||
Description |
The functions accept(), getpeername(), getsockname(), and recvfrom() include the arguments: struct sockaddr *restrict address, socken_t *restrict address_len In these functions, if address is not a null pointer, address_len points to a value-result parameter. On entry, *address_len is the number of bytes of space pointed to by address, and on successful return *address_len is filled in with the size of the resulting socket address (prior to any truncation) that was stored at address. Also the recvmsg() function takes a pointer to a structure which contains a similar "msg_namelen" value-result member. However the descriptions of these functions do not accurately describe this and omit information necessary to actually make use of these functions. The descriptions of getsockname() and getpeername() mention "the length of the supplied sockaddr structure" but neglect to explain how this is obtained. The only mention of the address_len argument is as a place to store the resulting length. The description of recvfrom() contains a table where each of the arguments is described, but the description of address_len in the table is misleading. It is a copy of the description from bind() where address_len is not even a pointer and is an input only. It should be similar to accept() where address_len is described as pointing to an object that is both read and written. Unfortunately the description of address_len under accept() is not completely accurate either. It states "Points to a socklen_t structure..." but socklen_t is not a structure; it is required to be an integer type. Also the description does not make sense in the case where there is no supplied sockaddr structure (i.e. when address is a null pointer); either address_len should also be permitted to be a null pointer or it should be stated that address_len is ignored if address is a null pointer. The description of recvmsg() neglects to mention that the msg_namelen member is both read and written, and neglects to mention the case where the actual address length is larger than the supplied length. The other four functions all state "If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address shall be truncated." The Desired Action documents existing behavior at least on Linux, Mac OS X, Solaris, and AIX. |
||||||
Desired Action |
At page 559 line 19380 section accept Change: Points to a socklen_t structure... to: Either a null pointer, if address is a null pointer, or a pointer to a socklen_t object... At page 1045 line 35015 section getpeername, and at page 1074 line 35838 section getsockname Insert the following sentence at the beginning of the paragraph: The address_len argument points to a socklen_t object which on input specifies the length of the supplied sockaddr structure, and on output specifies the length of the stored address. At page 1761 line 56282 section recvfrom Change: Specifies the length of the sockaddr structure pointed to by the address argument. to: Either a null pointer, if address is a null pointer, or a pointer to a socklen_t object which on input specifies the length of the supplied sockaddr structure, and on output specifies the length of the stored address. At page 1764 line 56387 section recvmsg Change: In the msghdr structure, the msg_name and msg_namelen members specify the source address if the socket is unconnected. If the socket is connected, the msg_name and msg_namelen members shall be ignored. The msg_name member may be a null pointer if no names are desired or required. to: In the msghdr structure, the msg_name member may be a null pointer if the source address is not required. Otherwise, if the socket is unconnected, the msg_name member points to a sockaddr structure in which the source address is to be stored, and the msg_namelen member on input specifies the length of the supplied sockaddr structure and on output specifies the length of the stored address. If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address shall be truncated. If the socket is connected, the msg_name and msg_namelen members shall be ignored. |
||||||
Tags | tc1-2008 | ||||||
Attached Files | |||||||
|
Relationships | |||||||
|
There are no notes attached to this issue. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |