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
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
related to 0001565Closed 1003.1(2016/18)/Issue7+TC2 Ambiguous which length addr_len is set to 

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-06-13 06:59 markh New Issue
2011-06-13 06:59 markh Status New => Under Review
2011-06-13 06:59 markh Assigned To => ajosey
2011-06-13 06:59 markh Name => Mark Harris
2011-06-13 06:59 markh Section => accept
2011-06-13 06:59 markh Page Number => 559
2011-06-13 06:59 markh Line Number => 19380
2011-06-16 15:53 Don Cragun Interp Status => ---
2011-06-16 15:53 Don Cragun Status Under Review => Resolved
2011-06-16 15:53 Don Cragun Resolution Open => Accepted
2011-06-16 15:53 Don Cragun Tag Attached: tc1-2008
2013-04-16 13:06 ajosey Status Resolved => Closed
2022-04-21 14:17 geoffclare Relationship added related to 0001565


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