[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] -- Michael Schuster Sun Microsystems, Inc. recursion, n: see 'recursion' _______________________________________________ networking-discuss mailing list [email protected]
