Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP Path: utzoo!watmath!clyde!cbosgd!ucbvax!ucdavis!lll-crg!mordor!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: The variable "errno". Message-ID: <3426@ut-sally.UUCP> Date: Fri, 8-Nov-85 21:38:51 EST Article-I.D.: ut-sally.3426 Posted: Fri Nov 8 21:38:51 1985 Date-Received: Sun, 10-Nov-85 10:02:09 EST Organization: IEEE/P1003 Portable Operating System Environment Committee Lines: 51 Approved: jsq@ut-sally.UUCP Date: 06 Oct 85 19:19:53 +1000 (Sun) >From: Robert ElzSection 2.3 of draft 4 [ Section 2.4 of Draft 5 -jsq ] of working group P1003 of (etc, etc of) IEEE states Errno is not changed on successful calls, ... This is a stronger statement than I would like to see. Again, my reason is that this introduces a distinction between the magic "system call" and the ordinary "library routine". [ No, it removes a distinction between them. It is really a misfeature that some library routines set errno when they have not failed. -Gwyn ] Much better would simply be to state (as I believe the ANSI C working group's draft states - though I can't find my copy right now) that "errno is defined only after unsuccessful calls to routines where it is explicitly stated to be set". That is, it is only meaningful to test errno after a function call that has returned an error indication, where that function has been documented to set errno to indicate the cause of the error. That includes all system calls, and some library routines. [ This is essentially what Draft 5 says about testing errno, although its wording is slightly confusing. -Gwyn ] [ Which is exactly the problem: even if you already know what it was supposed to mean, you have to read it a few times to see if it really does. This problem was mentioned by several people at the Steering Group meeting in Dallas. However, that group was not authorized by the committee to make substantive changes to the actual draft. But we did add a note in an Appendix explaining the problem, what the X3J11 draft currently says, and a proposed better wording. This will appear in Draft 6, so that it can be taken into account during the Trial Use balloting. I do not unfortunately have the text of that note, as I don't have Draft 6 yet. Don Kretsch plans to propose the same wording as that of the D6 appendix to X3J11 as a replacement for their current wording. -jsq ] With the caveat on the use of "errno" in section 3.3.2.5 I wonder if perhaps its days are not numbered. I would have to think what might replace it though. Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov Volume-Number: Volume 3, Number 6