errno usage.

errno usage.

[Luiz Fernando Capitulino]

Hi, hi, hi there!

  I have a question about 'errno' which I'm postponing for some
time: is it a bad pratice to set 'errno' by hand in libraries
and even in ordinary programs?

I mean, AFAIK 'errno' was created to store error codes from system
calls, but it's widely used by several libraries. Sometimes is even
helpful to set 'errno' in the program itself, something like:

int get_foobar_info(char *value)
{
	if (!value) {
		errno = EINVAL;
		return -1;
	}

...

	return 0;
}

Is it a bad pratice? Is there a 'limit' for 'errno' usage?

Thank you!

Re: errno usage.

[Glynn Clements]

Luiz Fernando Capitulino wrote:

>   I have a question about 'errno' which I'm postponing for some
> time: is it a bad pratice to set 'errno' by hand in libraries
> and even in ordinary programs?
> 
> I mean, AFAIK 'errno' was created to store error codes from system
> calls, but it's widely used by several libraries. Sometimes is even
> helpful to set 'errno' in the program itself, something like:
> 
> int get_foobar_info(char *value)
> {
> 	if (!value) {
> 		errno = EINVAL;
> 		return -1;
> 	}
> 
> ...
> 
> 	return 0;
> }
> 
> Is it a bad pratice? Is there a 'limit' for 'errno' usage?

No; there's no reason you can't use errno for your own purposes.

Many library functions will set errno; even if they don't set it
explicitly, they can call libc (etc) function which can set it.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: errno usage.

[Steve Graegert]

On 7/30/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> 
> Luiz Fernando Capitulino wrote:
> 
> >   I have a question about 'errno' which I'm postponing for some
> > time: is it a bad pratice to set 'errno' by hand in libraries
> > and even in ordinary programs?
> >
> > I mean, AFAIK 'errno' was created to store error codes from system
> > calls, but it's widely used by several libraries. Sometimes is even
> > helpful to set 'errno' in the program itself, something like:
> >
> > int get_foobar_info(char *value)
> > {
> >       if (!value) {
> >               errno = EINVAL;
> >               return -1;
> >       }
> >
> > ...
> >
> >       return 0;
> > }
> >
> > Is it a bad pratice? Is there a 'limit' for 'errno' usage?
> 
> No; there's no reason you can't use errno for your own purposes.

This is acceptable for most cases but is not recommended for
multithreaded applications since two or more threads may set the
globally defined errno variable to report errors, but its use may
result it nondeterministic behavior.  POSIX avoids the use of errno
and provides for mechanisms that enable access to thread-specific
errno variables.  Most POSIX.1c functions return the error code as the
return value with a value of zero indicating success.

When using errno in a multithreaded environment (which is not
explicitly recommended by POSIX but acceptable to retain
compatibility) ISO/IEC 9945:1-1996 defines that errno.h should be
included in every source file to make sure that every thread accesses
its own errno variable to check for errors.  This is crucial to create
libraries that conform to POSIX and are reentrant.
 
> Many library functions will set errno; even if they don't set it
> explicitly, they can call libc (etc) function which can set it.

When setting errno manually it is always a good idea to store its
previous value in a temporary variable to be able to restore it when
other function/library calls read it to check for errors afterwards.

Regards

        \Steve

Re: errno usage.

[Steve Graegert]

On 8/1/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> 
> Steve Graegert wrote:
> 
> > > > Is it a bad pratice? Is there a 'limit' for 'errno' usage?
> > >
> > > No; there's no reason you can't use errno for your own purposes.
> >
> > This is acceptable for most cases but is not recommended for
> > multithreaded applications since two or more threads may set the
> > globally defined errno variable to report errors, but its use may
> > result it nondeterministic behavior.
> 
> In GNU libc 2.x, errno is a macro which refers to a thread-specific
> location.

OK.  Thanks for the update.

> > When using errno in a multithreaded environment (which is not
> > explicitly recommended by POSIX but acceptable to retain
> > compatibility) ISO/IEC 9945:1-1996 defines that errno.h should be
> > included in every source file to make sure that every thread accesses
> > its own errno variable to check for errors.  This is crucial to create
> > libraries that conform to POSIX and are reentrant.
> 
> Just to clarify: if you read or set errno, you have to include
> <errno.h>; don't use "extern int errno" (which will work on some
> systems, but not with glibc).

Agree.  Lots of ancient SYSV code I have worked on a couple of months
ago caused a lot of headaches because of "extern int errno" statements
that turned out to cause even more confusion when used in
multithreaded environments.  Nice to read that glibc is properly
prepared.

Regards

        \Steve

Re: errno usage.

[Glynn Clements]

Steve Graegert wrote:

> > > Is it a bad pratice? Is there a 'limit' for 'errno' usage?
> > 
> > No; there's no reason you can't use errno for your own purposes.
> 
> This is acceptable for most cases but is not recommended for
> multithreaded applications since two or more threads may set the
> globally defined errno variable to report errors, but its use may
> result it nondeterministic behavior.

In GNU libc 2.x, errno is a macro which refers to a thread-specific
location.

> When using errno in a multithreaded environment (which is not
> explicitly recommended by POSIX but acceptable to retain
> compatibility) ISO/IEC 9945:1-1996 defines that errno.h should be
> included in every source file to make sure that every thread accesses
> its own errno variable to check for errors.  This is crucial to create
> libraries that conform to POSIX and are reentrant.

Just to clarify: if you read or set errno, you have to include
<errno.h>; don't use "extern int errno" (which will work on some
systems, but not with glibc).

-- 
Glynn Clements <glynn@gclements.plus.com>