C99 , POSIX and errno
Spiros Bousbouras
The value of errno should only be examined when it is indicated to
be valid by a function's return value.
[...]
The setting of errno after a successful call to a function is
unspecified
unless the description of that function specifies that errno shall
not be
modified.
Consider the following code
#include <stdio.h>
#include <errno.h>
int main(void) {
puts("Hi") ;
printf("errno is %d\n",errno) ; /* Possibly illegal
according to POSIX */
return 0 ;
}
If I'm understanding the POSIX quote correctly then the printf()
should
not be allowed if puts() does not return EOF. On the other hand I'm
sure
the above code is perfectly legal according to C99. So is this a clash
between POSIX and C99 ?
Eric Sosman
I don't see a clash. POSIX says that the errno holds an
unspecified value after puts(), but not that it holds or could
hold a trap representation. ISO C says errno starts with the
value zero and allows (sometimes requires) library functions to
assign other values to it, but assigning a "value" cannot
produce a trap representation.
james...@verizon.net
The C standard specifies that "The value of errno is zero at program
startup, but is never set to zero by any library
function. ..." (7.5p3). The web page he cited says that "The value of
errno shall be defined only after a call to a function for which it is
explicitly stated to be set... ". It seems to me that such wording
allows, possibly even requires, that errno have a value at the start
of a program which is indeterminate. This is not an accident. Wording
that matches 7.5p3 was very deliberately removed:
| Issue 5
|
| The following sentence is deleted from the DESCRIPTION: "The
value of errno is 0 at program start-up, but is
| never set to 0 by any XSI function".
Why that sentence was deleted is not specified; was it considered
redundant with C99 7.5p3? But it seems to make a broader promise than
7.5p3 - it covers XSI functions, whereas C99 7.5p3 only covers C
standard library functions.
Geoff Clare
> Wording
> that matches 7.5p3 was very deliberately removed:
>
> | Issue 5
> |
> | The following sentence is deleted from the DESCRIPTION: "The
> value of errno is 0 at program start-up, but is
> | never set to 0 by any XSI function".
>
> Why that sentence was deleted is not specified
Part of it duplicates a statement in the first paragraph:
No function in this volume of IEEE Std 1003.1-2001 shall set
errno to 0.
The other part, about program start-up, was probably removed because
Issue 5 was when threads were added. It doesn't make sense to talk
about errno being zero at program start-up when there can be threads
(which each have their own errno value) that didn't exist at program
start-up.
> But it seems to make a broader promise than
> 7.5p3 - it covers XSI functions, whereas C99 7.5p3 only covers C
> standard library functions.
In Issue 5 and earlier, "XSI" didn't mean the same as it does now.
It effectively referred to the entire specification, and so
"any XSI function" included the functions from the C Standard.
--
Geoff Clare <net...@gclare.org.uk>
james...@verizon.net
> jameskuyper wrote:
>
> > Wording
> > that matches 7.5p3 was very deliberately removed:
> >
> > | Issue 5
> > |
> > | The following sentence is deleted from the DESCRIPTION: "The
> > value of errno is 0 at program start-up, but is
> > | never set to 0 by any XSI function".
> >
> > Why that sentence was deleted is not specified
>
> Part of it duplicates a statement in the first paragraph:
>
> No function in this volume of IEEE Std 1003.1-2001 shall set
> errno to 0.
>
> The other part, about program start-up, was probably removed because
> Issue 5 was when threads were added. It doesn't make sense to talk
> about errno being zero at program start-up when there can be threads
> (which each have their own errno value) that didn't exist at program
> start-up.
I can think of at least two reasonable approaches for threaded code;
when a thread is created, it's own errno is initialized either with 0,
or with the value it had in the thread from which the new thread was
created. It seems unreasonable to me is to leave the initial value
unspecified. I speak as someone with only limited experience with
parallel computing. That experience was 18 years ago, and did not
involve POSIX threads.
> > But it seems to make a broader promise than
> > 7.5p3 - it covers XSI functions, whereas C99 7.5p3 only covers C
> > standard library functions.
>
> In Issue 5 and earlier, "XSI" didn't mean the same as it does now.
> It effectively referred to the entire specification, and so
> "any XSI function" included the functions from the C Standard.
Thus, as I said, it makes a broader promise than the one in the C
standard, one that extends to functions that the C standard's promise
doesn't cover.
Douglas A. Gwyn
news:1cdcba18-fe83-4648...@i76g2000hsf.googlegroups.com...
> Geoff Clare wrote:
>> ... It doesn't make sense to talk
>> about errno being zero at program start-up when there can be threads
>> (which each have their own errno value) that didn't exist at program
>> start-up.
> I can think of at least two reasonable approaches for threaded code;
> when a thread is created, it's own errno is initialized either with 0,
> or with the value it had in the thread from which the new thread was
> created. It seems unreasonable to me is to leave the initial value
Indeed, a standard for threads (WG21 has been working on one
and WG14 may buy into it to the extent needed for C) ought to
specify what happens to errno at the start of a thread. It still makes
sense to say what errno is at the start of a (possibly non-threaded)
program.