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
0001337 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Omission 2020-04-29 17:41 2020-12-09 10:06
Reporter eblake View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
Name Eric Blake
Organization Red Hat
User Reference accept vs setsockopt
Section XSH 2.10.16
Page Number 528
Line Number 18538
Interp Status ---
Final Accepted Text
Summary 0001337: Clarify socket option values after accept()
Description While the standard is clear that all sockets have default settings for socket options, and that some defaults are implementation-defined (for example, "The default value for the SO_RCVBUF option value is implementation-defined, and may vary by protocol." line 18628), it is silent on whether a non-default socket option set on a listening socket is required/permitted to be inherited into the new socket created by accept(). As there are existing implementations which inherit some but not all socket options (see https://stackoverflow.com/questions/5968132/are-socket-options-inherited-across-accept-from-the-listening-socket), [^] the best course of action is to just clarify that portable applications cannot rely on option inheritance.

Also, the text states "All of the options have defaults" (line 18538) then contradicts itself "SO_TYPE has no default value" (line 18672).
Desired Action [note: this change assumes that 0000411 adding accept4() is applied]

Change page 528 line 18538 (XSH 2.10.16 Use of Options) from:
All of the options have defaults.
to:
All of the options usable with setsockopt( ) have defaults. For each option where a default value is listed as implementation-defined, the implementation also controls whether a socket created by accept( ) or accept4( ) starts with the option reset to the original default value, or inherited as the value previously customized on the original listening socket.


At page 565 line 19882 [XSH accept() DESCRIPTION), add a paragraph:
It shall be implementation-defined which socket options, if any, on the accepted socket will have a default value determined by a value previously customized by setsockopt( ) on socket, rather than the default value used for other new sockets.


At page 569 line 19912 [XSH accept() APPLICATION USAGE), add a new paragraph:
Many socket options are described as having implementation-defined default values, which may differ according to the protocol in use by the socket. Existing practice differs on whether socket options such as SO_SNDBUF that were customized on the original listening socket will impact the corresponding option on the newly returned socket. Implementations are permitted to allow inheritance of customized settings where it makes sense, although the most portable approach for applications is to limit setsockopt( ) customizations to only the accepted socket.


At page 1924 line 62032 [XSH setsockopt() APPLICATION USAGE), add a new paragraph:
It is implementation-defined which socket options, if any, are inherited from a listening socket to an accepted socket by accept( ) or accept4( ).

Tags issue8
Attached Files

- Relationships
related to 0000411Appliedajosey 1003.1(2008)/Issue 7 adding atomic FD_CLOEXEC support 
related to 0001318Applied 1003.1(2016/18)/Issue7+TC2 Define close-on-fork flag 

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2020-04-29 17:41 eblake New Issue
2020-04-29 17:41 eblake Name => Eric Blake
2020-04-29 17:41 eblake Organization => Red Hat
2020-04-29 17:41 eblake User Reference => accept vs setsockopt
2020-04-29 17:41 eblake Section => XSH 2.10.16
2020-04-29 17:41 eblake Page Number => 528
2020-04-29 17:41 eblake Line Number => 18538
2020-04-29 17:41 eblake Interp Status => ---
2020-04-29 17:42 eblake Relationship added child of 0000411
2020-04-29 17:43 eblake Relationship added related to 0001318
2020-05-18 15:23 geoffclare Relationship replaced related to 0000411
2020-11-12 16:33 Don Cragun Status New => Resolved
2020-11-12 16:33 Don Cragun Resolution Open => Accepted
2020-11-12 16:33 Don Cragun Tag Attached: issue8
2020-12-09 10:06 geoffclare Status Resolved => Applied


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