View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00010671003.1(2013)/Issue7+TC1System Interfacespublic2016-08-11 08:342024-08-05 09:27
Reportergeoffclare Assigned To 
PrioritynormalSeverityObjectionTypeOmission
Status ClosedResolutionAccepted As Marked 
NameGeoff Clare
OrganizationThe Open Group
User Reference
Sectionsocket
Page Number1984
Line Number63551-63559
Interp Status---
Final Accepted TextSee 0001067:0003902
Summary0001067: missing socket() error for unsupported socket type
DescriptionThe ERRORS section for socket() does not list an error number to be
used when the socket type is not supported by the address family.
This is different from the condition listed for EPROTOTYPE: "The
socket type is not supported by the protocol" because, in
particular, the latter does not cover the case when the protocol
argument is zero.

I have observed three different behaviours on existing systems.
It looks like System V derivatives use EPROTOTYPE for this even
though no protocol was specified (tested on Solaris 11 and HP-UX 11).
OS X uses EPROTONOSUPPORT and Linux uses a non-standard error number
(ESOCKTNOSUPPORT).

The call I used to test this was socket(AF_INET, SOCK_SEQPACKET, 0).

The socketpair() page has the same problem.
Desired ActionThere are seven options (some only included for completeness and not
worth considering):

1. Only allow EPROTOTYPE

2. Only allow EPROTONOSUPPORT

3. Only allow ESOCKTNOSUPPORT

4. Allow EPROTOTYPE or EPROTONOSUPPORT

5. Allow EPROTOTYPE or ESOCKTNOSUPPORT

6. Allow EPROTONOSUPPORT or ESOCKTNOSUPPORT

7. Allow all three.

I will propose wording changes for socket() and socketpair() once the
group chooses one of these options.
Tagsissue8

Relationships

related to 0001846 Resolved 1003.1(2024)/Issue8 defect 1067 was only applied to socket() but applies to socketpair() too 

Activities

geoffclare

2017-12-15 11:52

manager   bugnote:0003902

In the Dec 14 teleconference it was decided to allow all three behaviours in Issue 8 but with OB shading and future directions as a warning that we intend to require ESOCKTNOSUPPORT in Issue 9.

Proposed changes:

(All page and line numbers are for the 2016 edition.)

On page 236 line 7959 section XBD <errno.h>, add:
[ESOCKTNOSUPPORT] Socket type not supported.

On page 487 line 16832 section XSH 2.3 Error Numbers, add:
[ESOCKTNOSUPPORT]
Socket type not supported. The socket type is not supported by the address family, or the socket type is not supported by the implementation.

On page 2005 line 64494-64497 section socket(), change:
[EPROTONOSUPPORT]
The protocol is not supported by the address family, or the protocol is not supported by the implementation.


[EPROTOTYPE]
The socket type is not supported by the protocol.
to:
[EPROTONOSUPPORT]
The value of protocol is non-zero and either the protocol is not supported by the address family or the protocol is not supported by the implementation.


[EPROTOTYPE]
The value of protocol is non-zero and the socket type is not supported by the protocol.


[ESOCKTNOSUPPORT] [OB]or [EPROTONOSUPPORT] or [EPROTOTYPE][/OB]
The socket type is not supported by the address family, or the socket type is not supported by the implementation.

On page 2005 line 64510-64513 section socket() change:
RATIONALE
None.


FUTURE DIRECTIONS
None.
to:
RATIONALE
Historically the standard did not specify the errno value to be used when the socket type is not supported, and there were differences between implementations. Some reused the existing standard [EPROTONOSUPPORT] or [EPROTOTYPE] values while others set errno to a (then) non-standard value of [ESOCKTNOSUPPORT]. All three values are permitted in this version of the standard, but the use of [EPROTONOSUPPORT] or [EPROTOTYPE] is considered to be misleading when no protocol is specified (that is, the value of protocol is zero) and consequently those alternatives have been marked obsolescent. If protocol is non-zero, since there is no precedence between error conditions, all three values will still be permitted even after the obsolescent alternatives for the [ESOCKTNOSUPPORT] condition have been removed.


FUTURE DIRECTIONS
A future version of this standard may disallow setting errno to [EPROTONOSUPPORT] or [EPROTOTYPE] when the socket type is not supported and protocol is zero.

Issue History

Date Modified Username Field Change
2016-08-11 08:34 geoffclare New Issue
2016-08-11 08:34 geoffclare Name => Geoff Clare
2016-08-11 08:34 geoffclare Organization => The Open Group
2016-08-11 08:34 geoffclare Section => socket
2016-08-11 08:34 geoffclare Page Number => 1984
2016-08-11 08:34 geoffclare Line Number => 63551-63559
2016-08-11 08:34 geoffclare Interp Status => ---
2017-12-15 11:52 geoffclare Note Added: 0003902
2018-01-04 16:22 nick Final Accepted Text => See 0001067:0003902
2018-01-04 16:22 nick Status New => Resolved
2018-01-04 16:22 nick Resolution Open => Accepted As Marked
2018-01-04 16:22 nick Tag Attached: issue8
2020-04-21 13:21 geoffclare Status Resolved => Applied
2024-06-11 08:55 agadmin Status Applied => Closed
2024-08-05 09:27 geoffclare Relationship added related to 0001846