Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001067 [1003.1(2013)/Issue7+TC1] System Interfaces Objection Omission 2016-08-11 08:34 2020-04-21 13:21
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Geoff Clare
Organization The Open Group
User Reference
Section socket
Page Number 1984
Line Number 63551-63559
Interp Status ---
Final Accepted Text See Note: 0003902
Summary 0001067: missing socket() error for unsupported socket type
Description The 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 Action There 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.
Tags issue8
Attached Files

- Relationships

-  Notes
(0003902)
geoffclare (manager)
2017-12-15 11:52

 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 Note: 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

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