Preserving the value of errno

[Spiros Bousbouras]

Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;

Is this ok ?

[Pietro Cerutti]

Spiros Bousbouras wrote:

Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;

Is this ok ?

Why not just set errno to your error before returning when something
goes wrong?
--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[jacob navia]

Pietro Cerutti wrote:

Spiros Bousbouras wrote:

>Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;

Is this ok ?

Why not just set errno to your error before returning when something
goes wrong?

!!!!!

Very good answer.

[Mark Bluemel]

Pietro Cerutti wrote:

Spiros Bousbouras wrote:

>>Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;

Is this ok ?

Why not just set errno to your error before returning when something
goes wrong?

I assumed he wanted to guard against it being changed by any functions
he called in turn...

[Pietro Cerutti]

Mark Bluemel wrote:

Pietro Cerutti wrote:

>Spiros Bousbouras wrote:

>>Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;

Is this ok ?

Why not just set errno to your error before returning when something
goes wrong?

I assumed he wanted to guard against it being changed by any functions
he called in turn...

Sorry, I misread the OP's post.

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[Richard Heathfield]

Pietro Cerutti said:

Mark Bluemel wrote:

>Pietro Cerutti wrote:

<snip>

>>Why not just set errno to your error before returning when something
goes wrong?

I assumed he wanted to guard against it being changed by any
functions he called in turn...

Sorry, I misread the OP's post.

Easily done, isn't it? <sighAh well, tomorrow is another day.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Al Balmer]

On Mon, 30 Jul 2007 16:34:47 -0000, Spiros Bousbouras
<sp****@gmail.comwrote:

>Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;

Is this ok ?

Sure. It's not something that's often useful, but I have written
library routines that did this. You might, for example, want to
capture an error return from another function, then return either that
or some other error depending on further processing.

--
Al Balmer
Sun City, AZ

[Pietro Cerutti]

Richard Heathfield wrote:

Pietro Cerutti said:

>Mark Bluemel wrote:

>>Pietro Cerutti wrote:

<snip>

>>>Why not just set errno to your error before returning when something
goes wrong?
I assumed he wanted to guard against it being changed by any
functions he called in turn...

Sorry, I misread the OP's post.

Easily done, isn't it? <sighAh well, tomorrow is another day.

Yes it is. What's the problem?

Sorry, I don't want to embark in off-topical debates, but what's wrong
with you?

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[Richard Heathfield]

Pietro Cerutti said:

Sorry, I don't want to embark in off-topical debates, but what's wrong
with you?

I don't know. We all have our off-days, n'est-ce-pas? Well, I suppose
that today (actually, yesterday, as of four minutes ago) just happened
to be mine.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Pietro Cerutti]

Richard Heathfield wrote:

Pietro Cerutti said:

>Sorry, I don't want to embark in off-topical debates, but what's wrong
with you?

I don't know. We all have our off-days, n'est-ce-pas? Well, I suppose
that today (actually, yesterday, as of four minutes ago) just happened
to be mine.

No problem with that, best wishes for tomorrow (actually, today) ;-)

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[Spiros Bousbouras]

On Jul 30, 6:21 pm, Eric Sosman <[e-mail]:

Spiros Bousbouras wrote:

>Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;

>Is this ok ?

errno is a less-than-wonderful mechanism, agreed.
But occasionally it's useful to preserve an errno value
"just in case" it holds something that might be useful.
The O.P.'s use case doesn't make much sense to me (if
the caller cares about a pre-existing errno value, the
caller should grab it before calling other functions)...

Indeed the caller could but I consider it The Right Thing
that a function which is going to use errno should only
modify it if something went wrong. I believe it makes
things overall more tidy. I actually believe that the
standard should specify that library functions should
only modify errno if something went wrong.

Consider the Unix specific readdir() For those not familiar
with it it returns successive directory entries on a Unix
system. You first open the directory with opendir() and
then you read the files by calling readdir() again and again.
readdir() will return a NULL pointer if it encounters an error
of if there are no more files to be read. So once readdir()
returns NULL the only way to tell if it was an error or the
end of the directory is to test the value of errno. This in
turns means that if you have a loop which is meant to read
all the directory entries then you have to set errno to 0
*every* time the loop gets repeated. On the other hand if it
was guaranteed that readdir() would only modify errno if
something went wrong and your loop only called readdir() then
you would only have to set errno to 0 once before entering
the loop.

This is as an example of why I feel that a function should
only modify errno if something went wrong. It's perhaps
a stylistic preference more than anything else but I do
prefer it.

[Eric Sosman]

Spiros Bousbouras wrote:

On Jul 30, 6:21 pm, Eric Sosman <[e-mail]:

>>Spiros Bousbouras wrote:
Assume I'm writing a function which is going to set
the value of errno if something went wrong but I also
want to guarantee that errno will remain unchanged
if the function completed its task succesfully. So at
the beginning of my code I have something like
int errsto = errno ;
and just before every successful return I have
errno = errsto ;
Is this ok ?

> errno is a less-than-wonderful mechanism, agreed.
But occasionally it's useful to preserve an errno value
"just in case" it holds something that might be useful.
The O.P.'s use case doesn't make much sense to me (if
the caller cares about a pre-existing errno value, the
caller should grab it before calling other functions)...

Indeed the caller could but I consider it The Right Thing
that a function which is going to use errno should only
modify it if something went wrong. I believe it makes
things overall more tidy. I actually believe that the
standard should specify that library functions should
only modify errno if something went wrong.

Consider the Unix specific readdir() For those not familiar
with it it returns successive directory entries on a Unix
system. You first open the directory with opendir() and
then you read the files by calling readdir() again and again.
readdir() will return a NULL pointer if it encounters an error
of if there are no more files to be read. So once readdir()
returns NULL the only way to tell if it was an error or the
end of the directory is to test the value of errno. This in
turns means that if you have a loop which is meant to read
all the directory entries then you have to set errno to 0
*every* time the loop gets repeated. On the other hand if it
was guaranteed that readdir() would only modify errno if
something went wrong and your loop only called readdir() then
you would only have to set errno to 0 once before entering
the loop.

Same amount of source code in either case, just
differently positioned. Nor is there likely to be any
gain in efficiency, because the fact that your `errno = 0;'
moves out of the loop is offset by the fact that readdir()
must now preserve and restore `errno' on every call.

This is as an example of why I feel that a function should
only modify errno if something went wrong. It's perhaps
a stylistic preference more than anything else but I do
prefer it.

Your preferences are your business, of course, but they
don't happen to be enforced by the Standard. Question 12.24
in the FAQ provides a pretty good hint about why this is so.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Richard Tobin]

In article <6o******************************@comcast.com>,
Eric Sosman <es*****@ieee-dot-org.invalidwrote:

>Nor is there likely to be any
gain in efficiency, because the fact that your `errno = 0;'
moves out of the loop is offset by the fact that readdir()
must now preserve and restore `errno' on every call.

Only if it does something that may change it when no error has
occurred.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Spiros Bousbouras]

On 8 Aug, 14:05, Eric Sosman <[e-mail]:

Spiros Bousbouras wrote:

The O.P.'s use case doesn't make much sense to me (if
the caller cares about a pre-existing errno value, the
caller should grab it before calling other functions)...

Indeed the caller could but I consider it The Right Thing
that a function which is going to use errno should only
modify it if something went wrong. I believe it makes
things overall more tidy. I actually believe that the
standard should specify that library functions should
only modify errno if something went wrong.

Consider the Unix specific readdir() For those not familiar
with it it returns successive directory entries on a Unix
system. You first open the directory with opendir() and
then you read the files by calling readdir() again and again.
readdir() will return a NULL pointer if it encounters an error
of if there are no more files to be read. So once readdir()
returns NULL the only way to tell if it was an error or the
end of the directory is to test the value of errno. This in
turns means that if you have a loop which is meant to read
all the directory entries then you have to set errno to 0
*every* time the loop gets repeated. On the other hand if it
was guaranteed that readdir() would only modify errno if
something went wrong and your loop only called readdir() then
you would only have to set errno to 0 once before entering
the loop.

Same amount of source code in either case, just
differently positioned. Nor is there likely to be any
gain in efficiency, because the fact that your `errno = 0;'
moves out of the loop is offset by the fact that readdir()
must now preserve and restore `errno' on every call.

The positioning of code is important. I believe that annoying
little details should be dealt with at the lowest level possible
unless there are other (good) reasons to do otherwise and in
this case I don't feel there are. Nor is it necessary only a
matter of code positioning. If all the library functions
guaranteed that errno would only be modified in the case of an
error then many would not have to take any explicit measures
to preserve it. The exceptions would be functions in implementations
like those mentioned in FAQ 12.24 or functions which could do
their job in more than one ways and I feel these are a minority.