std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/09/85)
Date: 06 Oct 85 19:19:53 +1000 (Sun)
>From: Robert Elz <munnari!kre@seismo.CSS.GOV>
Section 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