View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001929 | 1003.1(2024)/Issue8 | System Interfaces | public | 2025-06-11 20:04 | 2025-07-10 16:27 |
| Reporter | gleb.smirnoff | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Error |
| Status | Resolved | Resolution | Accepted As Marked | ||
| Name | Gleb Smirnoff | ||||
| Organization | |||||
| User Reference | |||||
| Section | recv(), recvfrom(), recvmsg() | ||||
| Page Number | 1 | ||||
| Line Number | paragraph on length of the message | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001929:0007217 | ||||
| Summary | 0001929: features of SOCK_SEQPACKET in documentation of certain System Interfaces contradict its definition in the Base Definitions | ||||
| Description | The SOCK_SEQPACKET is defined in the Base Definitions: https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_10_06 "The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type, and is also connection-oriented. The only difference between these types is that record boundaries are maintained using the SOCK_SEQPACKET type. A record can be sent using one or more output operations and received using one or more input operations, but a single operation never transfers parts of more than one record. Record boundaries are visible to the receiver via the MSG_EOR flag in the received message flags returned by the recvmsg() function. It is protocol-specific whether a maximum record size is imposed." The same idea is also reiterated in the core System Interfaces related to sockets: socket() and socketpair(): https://pubs.opengroup.org/onlinepubs/9799919799/functions/socket.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/socketpair.html However, three System Interfaces for receiving data from sockets, namely recv(), recvfrom() and recvmsg() say something that totally contradicts the base definition: https://pubs.opengroup.org/onlinepubs/9799919799/functions/recv.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/recvfrom.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/recvmsg.html "For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes shall be discarded." This statement strongly contradicts base definition of SOCK_SEQPACKET. | ||||
| Desired Action | Minimal desired fix would be to just remove words "and SOCK_SEQPACKET" from recv(), recvfrom() and recvmsg(). A better fix would also improve wording of the corresponding paragraphs on different kinds of sockets: 1) Don't mention SOCK_SEQPACKET together with SOCK_DGRAM. Add SOCK_RAW where it is missing. 2) Don't use "message boundaries" in the description of SOCK_STREAM. Use "size of output operation" instead. 3) Add a full sentence for SOCK_SEQPACKET. For recv() and recvfrom() the improved paragraph shall be: "The recv() function shall return the length of the message written to the buffer pointed to by the buffer argument. For message-based sockets, such as SOCK_DGRAM and SOCK_RAW, the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes shall be discarded. For stream-based sockets, such as SOCK_STREAM, size of input operation may not match size of sender's output operation. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded. For stream-based sockets with record boundaries, such as SOCK_SEQPACKET, size of input operation shall not cross a record boundary. However, the interface doesn't provide a way to differentiate an end of a record from a short read, hence for SOCK_SEQPACKET recommended interfaces is recvmsg()". For recvmsg() the improved paragraph shall be: "The recvmsg() function shall return the total length of the message. For message-based sockets, such as SOCK_DGRAM and SOCK_RAW, the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffers, and MSG_PEEK is not set in the flags argument, the excess bytes shall be discarded, and MSG_TRUNC shall be set in the msg_flags member of the msghdr structure. For stream-based sockets, such as SOCK_STREAM, size of input operation may not match size of sender's output operation. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded. For stream-based sockets with record boundaries, such as SOCK_SEQPACKET, size of input operation shall not cross a record boundary. An operation that ends on a record boundary shall set MSG_EOR in the msg_flags member of the msghdr structure." | ||||
| Tags | tc1-2024 | ||||
|
|
Suggested changes (reusing wording from XSH 2.10.6) ... On page 1875 line 61902 section recv(), and page 1878 line 61997 section recvfrom(), and page 1881 line 62113 section recvmsg(), change: For message-based sockets, such as [...], the entire message shall be read in a single operation.to: For message-based sockets, such as SOCK_DGRAM [RS]and SOCK_RAW[/RS], the entire message shall be read in a single operation. On page 1875 line 61905 section recv(), and page 1878 line 62000 section recvfrom(), change: For stream-based sockets, such as SOCK_STREAM, message boundaries shall be ignored. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded.to: For stream-based sockets, such as SOCK_STREAM, record boundaries shall be ignored; data sent on a stream-based socket using output operations of one size can be received using input operations of smaller or larger sizes; data shall be returned to the user as soon as it becomes available and no data shall be discarded. For stream-based sockets with maintained record boundaries, such as SOCK_SEQPACKET, a record can be sent using one or more output operations and received using one or more input operations, but a single operation shall never transfer parts of more than one record; in order to differentiate the end of a record from a short read, it is necessary to use the recvmsg() function instead of recv() or recvfrom(). On page 1881 line 62117 section recvmsg(), change: For stream-based sockets, such as SOCK_STREAM, message boundaries shall be ignored. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded.to: For stream-based sockets, such as SOCK_STREAM, record boundaries shall be ignored; data sent on a stream-based socket using output operations of one size can be received using input operations of smaller or larger sizes; data shall be returned to the user as soon as it becomes available and no data shall be discarded. For stream-based sockets with maintained record boundaries, such as SOCK_SEQPACKET, a record can be sent using one or more output operations and received using one or more input operations, but a single operation shall never transfer parts of more than one record; if the received data ends on a record boundary, MSG_EOR shall be set in the msg_flags member of the msghdr structure. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-06-11 20:04 | gleb.smirnoff | New Issue | |
| 2025-06-11 20:04 | gleb.smirnoff | Status | New => Under Review |
| 2025-06-11 20:04 | gleb.smirnoff | Assigned To | => ajosey |
| 2025-06-12 08:53 | geoffclare | Project | 1003.1(2004)/Issue 6 => 1003.1(2024)/Issue8 |
| 2025-06-30 14:25 | geoffclare | Note Added: 0007217 | |
| 2025-07-10 16:27 | geoffclare | Status | Under Review => Resolved |
| 2025-07-10 16:27 | geoffclare | Resolution | Open => Accepted As Marked |
| 2025-07-10 16:27 | geoffclare | Interp Status | => --- |
| 2025-07-10 16:27 | geoffclare | Final Accepted Text | => 0001929:0007217 |
| 2025-07-10 16:27 | geoffclare | Tag Attached: tc1-2024 |
