0000464: Inaccurate address_len description in socket functions

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

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

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.

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