|
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 |
2024-06-11 09:08 |
|
|
Reporter |
eblake |
View Status |
public |
|
|
Assigned To |
|
|
Priority |
normal |
Resolution |
Accepted |
|
|
Status |
Closed |
|
|
|
|
|
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 
