returning error from main()

[junky_fellow]

Guys,

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

eg.

int main(void)
{
int error;

if ((error = func()) 0) {
return(error); /* Is this Ok. ? */
}

return 0;
}

Otherwise, if this is not the right thing, what else should be done ?

[Ben Pfaff]

"ju**********@y ahoo.co.in" <ju**********@y ahoo.co.inwrite s:

int main(void)
{
int error;

if ((error = func()) 0) {
return(error); /* Is this Ok. ? */
}

return 0;
}

This seems like a bad idea, for at least three reasons. First, C
only defines the meaning of three return values from main (to
wit, 0, EXIT_FAILURE, and EXIT_SUCCESS). Second, many operating
systems in practice ascribe specific meanings to specific return
values (e.g. VMS) or have a severely limited range of return
values (e.g. Unix). Third, this is not a convention that I have
encountered anywhere.

Otherwise, if this is not the right thing, what else should be done ?

Typical would be to write an explanatory message to stderr and
return EXIT_FAILURE.
--
char a[]="\n .CJacehknorstu" ;int putchar(int);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,0x11f6} ,*p
=b,i=24;for(;p+ =!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Keith Thompson]

"ju**********@y ahoo.co.in" <ju**********@y ahoo.co.inwrite s:

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

eg.

int main(void)
{
int error;

if ((error = func()) 0) {
return(error); /* Is this Ok. ? */
}

return 0;
}

Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

There's normally no particular relationship between errno values and
values passed to exit(). It's tempting to thing that there is, since
0 means "no error" for both, but the non-zero values don't match,
either in standard C or on any system I'm familiar with.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

On Wed, 19 Sep 2007 00:38:43 -0700, Keith Thompson wrote:

"ju**********@y ahoo.co.in" <ju**********@y ahoo.co.inwrite s:

Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

M$ has lots of their "safe" functions returning an errno_t, such
as errno_t fopen_s(FILE **, const char *, const char *);
errno_t is a typedef for int, and the value returned is 0 on
success and errno on failure.
(I'm still trying to figure out why that should be considered
"safer".)
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[jacob navia]

Army1987 wrote:

On Wed, 19 Sep 2007 00:38:43 -0700, Keith Thompson wrote:

>"ju**********@ yahoo.co.in" <ju**********@y ahoo.co.inwrite s:

>Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

M$ has lots of their "safe" functions returning an errno_t, such
as errno_t fopen_s(FILE **, const char *, const char *);
errno_t is a typedef for int, and the value returned is 0 on
success and errno on failure.
(I'm still trying to figure out why that should be considered
"safer".)

Because of a better error analysis. That's why is safer.

1) None of its arguments should be NULL.
Those are constraints in the input arguments.
2) If there is a runtime constraint violation, the FILE ** argument
is set to NULL and an error return code is given to the calling
application.

This is much better than just getting a NULL and
trying to figure out why. The fopen specs just says "fopen returns
NULL on failure", not even leaving some errno mention...
No error analysis, like many other functions of the current
standard.

[Army1987]

On Tue, 18 Sep 2007 21:34:38 -0700, ju**********@ya hoo.co.in wrote:

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

The only value guaranteed to portably indicate failure is
EXIT_FAILURE in stdlib.h. For example, on Unix-like systems the
return status is clipped to the last eight bits, so returning
256, or 512 for example, would actually indicate success. (Yes,
errno codes don't usually go that high, but I think you get the
point.)
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[Richard Tobin]

In article <11************ **********@q3g2 000prf.googlegr oups.com>,
ju**********@ya hoo.co.in <ju**********@y ahoo.co.inwrote :

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

You need to consider the environment in which your program will be
used. Will it be used on an operating system where the full range of
error values can be returned? That's not guaranteed by the C
standard. Will those values be useful to someone running the program?

Someone using the program interactively will find it more useful to
have an error message printed ("foo: file not found" for example)
rather than having to decide a return value. Someone using the
program as part of a script may benefit from being able to test the
exit status, but will it really be useful for the script to
distinguish between all the different values?

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

[Ben Bacarisse]

jacob navia <ja***@jacob.re mcomp.frwrites:

Army1987 wrote:

>On Wed, 19 Sep 2007 00:38:43 -0700, Keith Thompson wrote:

>>"ju********** @yahoo.co.in" <ju**********@y ahoo.co.inwrite s:

>>Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

M$ has lots of their "safe" functions returning an errno_t, such
as errno_t fopen_s(FILE **, const char *, const char *);
errno_t is a typedef for int, and the value returned is 0 on
success and errno on failure.
(I'm still trying to figure out why that should be considered
"safer".)

Because of a better error analysis. That's why is safer.

This is and odd point of view. fopen can used quite safely and
fopen_s can be used unsafely.

1) None of its arguments should be NULL.
Those are constraints in the input arguments.
2) If there is a runtime constraint violation, the FILE ** argument
is set to NULL and an error return code is given to the calling
application.

You don't mean that (I hope).

This is much better than just getting a NULL and
trying to figure out why. The fopen specs just says "fopen returns
NULL on failure", not even leaving some errno mention...

The standard allows any library function to set errno how it likes
(provided that does not clash with a specified setting) but it wisely
does not require anything more from fopen, since some environments may
not be able to provide anything more.

Good implementations provide error information about fopen failures
through errno. Mandating that this number be returned does not
improve the "error analysis".

The real reason is, I suspect, that MS would like to create a buzz
around the idea that they care about "security". I am not so
absolutist that I think there will be no benefit from these new
"safer" functions -- there may well be a class of programmer who can't
write safe C without them and will be able to with them -- but I
suspect theat class is small, and the improvement will be
insignificant.

I do object to cluttering an already crowded name space with functions
that can be implemented in standard C. If the committee feels obliged
to follow this new proposal I would hope they can find a way to make
it optional for those of us who are happy with what is there already
(e.g. by putting them in new header files -- maybe stdios.h, stdlibs.h
and so on).

--
Ben.

[Army1987]

On Wed, 19 Sep 2007 18:28:05 +0100, Ben Bacarisse wrote:

jacob navia <ja***@jacob.re mcomp.frwrites:

[Why is M$'s fopen_s() safer than fopen()?]

>Because of a better error analysis. That's why is safer.

This is and odd point of view. fopen can used quite safely and
fopen_s can be used unsafely.

Indeed. I can't see any difference between using

err = fopen_s(&fp, filename, "rb+");
if (err)
do_something(er r);

and

fp = fopen(filename, "rb+");
if (fp == NULL)
do_something(er r);

in either ease of use, or usefulness. M$ is allowed to decide that
fopen() should always set errno when it returns NULL, and it is
allowed to decide what happens when either argument is a null
pointer.

>1) None of its arguments should be NULL.
Those are constraints in the input arguments.

Wow. What an error extremely likely to be done. On which fraction
of times you used fopen() or fopen_s() the last argument wasn't
a string literal? As for the filename, it is still very uneasy
to accidentally pass a null pointer...

>2) If there is a runtime constraint violation, the FILE ** argument
is set to NULL and an error return code is given to the calling
application.

You don't mean that (I hope).

Even if he meant that the pointer object pointed by the FILE **
argument is set to NULL, I can't see how this helps...
[snip]

The real reason is, I suspect, that MS would like to create a buzz
around the idea that they care about "security". I am not so
absolutist that I think there will be no benefit from these new
"safer" functions -- there may well be a class of programmer who can't
write safe C without them and will be able to with them -- but I
suspect theat class is small, and the improvement will be
insignificant.

Indeed, there are functions which are saner than their ISO C
counterparts (strncpy_s, gets_s...) or do something different
(rand_s), but in the case of fopen_s() I can't see any
improvement, no matter how hard I try to imagine.

I do object to cluttering an already crowded name space with functions
that can be implemented in standard C. If the committee feels obliged
to follow this new proposal I would hope they can find a way to make
it optional for those of us who are happy with what is there already
(e.g. by putting them in new header files -- maybe stdios.h, stdlibs.h
and so on).

M$'s standard C headers only declare them (or some of them, I'm
not sure) if some macro beginning with underscores is defined
before they're #include'd, unlike some (most?) standard headers of
lcc-win32, which have declarations not in ISO C not guarded by any
#if or #ifdef.

--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[jacob navia]

Flash Gordon wrote:

Returning 1 (or any odd value) on VMS will indicate success. I.e. you
should replace "probably safe on all systems" with "definitely wrong on
some systems but probably safe on most current systems."

Ahh VMS...
I am glad it disappeared.

You are right. I stand corrected for VMS.