The RETURN VALUES section of socket(3SOCKET) currently reads:
RETURN VALUES
A -1 is returned if an error occurs. Otherwise the return
value is a descriptor referencing the socket.
It does not explicitly state that errno is set.
Normally the RETURN VALUES section reads something like this:
RETURN VALUES
Upon successful completion, a descriptor referencing the
socket is returned. Otherwise, -1 is returned and errno is
set to indicate the error.
Thanks
Doug
michael schuster wrote:
> [EMAIL PROTECTED] wrote:
>
>> Can someone tell me if the socket() function sets errno on failure.
>> The man page does not
>> state as much, but lists errno values in the ERRORS section.
>
>
> well, IMO it can't be stated much more explicitly than it is now -
> where else than under ERRORS would you put that?
> not a bug, IMO.
>
> michael
>
>> Thanks
>> Doug
>>
>> -------- Original Message --------
>> Subject: CR 6421256 douglas.stevenson, Now responsible engineer
>> P4 manpage/section3sock socket(3SOCKET) man page makes little mention
>> of errno for returning errors
>> Date: Tue, 28 Aug 2007 10:42:44 -0600 (MDT)
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED], [EMAIL PROTECTED],
>> [EMAIL PROTECTED]
>>
>>
>>
>> *Synopsis*: socket(3SOCKET) man page makes little mention of errno
>> for returning errors
>> http://bt2ws.central.sun.com/CrPrint?id=6421256
>>
>> Due to a change requested by [EMAIL PROTECTED],
>> [EMAIL PROTECTED] is now the responsible engineer for:
>>
>> CR 6421256 changed on Aug 28 2007 by [EMAIL PROTECTED]
>>
>> === Field ============ === New Value ============= === Old Value
>> =============
>>
>> Responsible Engineer [EMAIL PROTECTED]
>> [EMAIL PROTECTED] ======================
>> =========================== ===========================
>>
>>
>> *Change Request ID*: 6421256
>>
>> *Synopsis*: socket(3SOCKET) man page makes little mention of errno
>> for returning errors
>>
>> Product: solaris
>> Category: manpage
>> Subcategory: section3socket
>> Type: Defect
>> Subtype: Status: 3-Accepted
>> Substatus: Priority: 4-Low
>> Introduced In Release: Introduced In Build: Responsible
>> Manager: [EMAIL PROTECTED]
>> Responsible Engineer: [EMAIL PROTECTED]
>> Initial Evaluator: [EMAIL PROTECTED]
>> Keywords: errno, socket
>>
>> === *Description*
>> ============================================================
>> The man page for socket(3SOCKET) does not state whether errno is set
>> to qualify an error in the case of a failure.
>>
>> *** (#1 of 1): 2006-05-03 15:02:59 GMT+00:00 [EMAIL PROTECTED]
>> *** Last Edit: 2006-05-03 15:02:59 GMT+00:00 [EMAIL PROTECTED]
>>
>>
>> === *Comments*
>> ===============================================================
>> The only hint that errno might be set is here:
>>
>> If ...
>> then the connection is considered broken and calls will
>> indicate an error with -1 returns and with ETIMEDOUT as the
>> specific code in the global variable errno. The protocols
>> ...
>>
>>
>> The return values section makes no mention of errno at all:
>>
>> RETURN VALUES
>> A -1 is returned if an error occurs. Otherwise the return
>> value is a descriptor referencing the socket.
>>
>>
>> Yet the "ERRORS" section implies that errno is set:
>>
>> ERRORS
>> The socket() function will fail if:
>>
>> EACCES Permission to create a socket of the
>> specified type or protocol is
>> denied.
>> etc...
>>
>>
>> It seems to state the failure modes, but doesn't actually go as far
>> as stating that these return codes are set in errno.
>>
>>
>> Looking at the implementation of socket() in libsocket on
>> aggregate.eng (onnv_nightly/source/usr/src/stand/lib/sock/socket.c)
>> it seems that a valid value for errno is set if the call to socket()
>> fails.
>>
>> I presume this is simply a man page bug and the RETURN VALUES section
>> needs a little rewording to explicitly state that errno is set (if
>> this is correct to say). I would appreciate clarification on whether
>> errno can be relied upon in the case of socket() returning -1.
>>
>> *** (#1 of 2): 2006-05-03 15:02:59 GMT+00:00 [EMAIL PROTECTED]
>> *** Last Edit: 2006-05-03 15:02:59 GMT+00:00 [EMAIL PROTECTED]
>>
>> Correction to source location:
>>
>> I think I was looking at the wrong bit of source code. I think the
>> correct bit is actually _socket_create:
>>
>> onnv_nightly/source/usr/src/lib/libsocket/socket/socket.c
>>
>> However, the comment remains the same about whether errno can be
>> relied upon, and whether this should be mentioned explicitly in the
>> man page.
>>
>> *** (#2 of 2): 2006-05-03 15:23:57 GMT+00:00 [EMAIL PROTECTED]
>> *** Last Edit: 2006-05-03 15:23:57 GMT+00:00 [EMAIL PROTECTED]
>>
>>
>> === *Evaluation*
>> =============================================================
>> Accepted. Will investigate.
>>
>> *** (#1 of 1): 2006-05-04 18:34:17 GMT+00:00 [EMAIL PROTECTED]
>> *** Last Edit: 2006-05-04 18:34:17 GMT+00:00 [EMAIL PROTECTED]
>>
>>
>> === *Suggested Fix*
>> ==========================================================
>>
>> === *Workaround*
>> =============================================================
>>
>> === *Justification*
>> ==========================================================
>>
>> === *Additional Details*
>> =====================================================
>> Targeted Release: Commit To Fix In Build:
>> Fixed In Build: Integrated In Build: Verified In
>> Build: See Also: Duplicate of: Hooks:
>> Hook1: Hook2: Hook3: Hook4:
>> Hook5: Hook6: Interest List: Program Management: Root
>> Cause: Requires Security Coordination: false
>> Fix Affects Documentation: No
>> Fix Affects Localization: No
>> Reported by:
>> === *History*
>> ================================================================
>> Date Submitted: 2006-05-03 15:02:57 GMT+00:00
>> Submitted By: [EMAIL PROTECTED]
>>
>> Status Changed Date Updated Updated By
>> 3-Accepted 2006-05-04 18:34:16 GMT+00:00
>> [EMAIL PROTECTED]
>>
>>
>> === *Solution*
>> ===============================================================
>>
>>
>> === *Service Request*
>> ========================================================
>> ID: 1-193656808
>> Customer:
>> Account Name: Sun Microsystems Enterprise Services UK
>> Contact Role: T-Technical Support
>> Impact: Limited
>> Functionality: Nonessential
>> Severity: 5
>> Synopsis: Product Name: solaris
>> Product Release: solaris_nevada
>> Product Build: snv_38
>> Operating System: snv_38
>> Hardware: generic_sparc
>> Reference Number: Sun Contact: [EMAIL PROTECTED]
>> Customer Contact: Contact Type: I-Internal (SMI)
>> Customer
>> Status: Open
>> Source: BugTraq2
>> Reproducible: Submitted By: [EMAIL PROTECTED]
>> Submitted Date: 2006-05-03 15:02:59 GMT+00:00
>> Description:
>>
>> === *Activity*
>> ===============================================================
>>
>>
>> === *Multiple Release (MR) Cluster* - 0
>> ======================================
>>
>>
>>
>> === *Escalations*
>> ============================================================
>>
>>
>> _______________________________________________
>> networking-discuss mailing list
>> [email protected]
>
>
>
_______________________________________________
networking-discuss mailing list
[email protected]
