Check all errors in code?

[lovecreatesbea...]

Do you check all error conditions for all library calls in you code?

Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice (If
it is, why ANSI atoi doesn't do it)?

/* <quote file=../net-snmp-5.4.1.1/snmplib/vacm.c*/

286 char *
287 _vacm_parse_config_access_common(struct vacm_accessEntry
**aptr, char *line)
288 {
289 struct vacm_accessEntry access;
290 char *cPrefix = (char *) &access.contextPrefix;
291 char *gName = (char *) &access.groupName;
292 size_t len;
293
294 access.status = atoi(line);
295 line = skip_token(line);
296 access.storageType = atoi(line);
297 line = skip_token(line);
298 access.securityModel = atoi(line);
299 line = skip_token(line);
300 access.securityLevel = atoi(line);
301 line = skip_token(line);
302 access.contextMatch = atoi(line);
303 line = skip_token(line);
304 len = sizeof(access.groupName);
305 line = read_config_read_octet_string(line, (u_char **)
&gName, &len);
306 len = sizeof(access.contextPrefix);
307 line = read_config_read_octet_string(line, (u_char **)
&cPrefix, &len);
308
309 *aptr = vacm_getAccessEntry(access.groupName,
310 access.contextPrefix,
311 access.securityModel,
312 access.securityLevel);
313 if (!*aptr)
314 *aptr = vacm_createAccessEntry(access.groupName,
315 access.contextPrefix,
316 access.securityModel,
317 access.securityLevel);
318 if (!*aptr)
319 return NULL;
320
321 (*aptr)->status = access.status;
322 (*aptr)->storageType = access.storageType;
323 (*aptr)->securityModel = access.securityModel;
324 (*aptr)->securityLevel = access.securityLevel;
325 (*aptr)->contextMatch = access.contextMatch;
326 return line;
327 }

/* </quote*/

[Ian Collins]

[e-mail] wrote:

Do you check all error conditions for all library calls in you code?

Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice (If
it is, why ANSI atoi doesn't do it)?

There is no way to check the result of atoi, that's why it's better to
use strtol in most situations.

--
Ian Collins.

[lovecreatesbea...]

On Sep 19, 4:08 pm, Ian Collins <[e-mail]:

[e-mail] wrote:

Do you check all error conditions for all library calls in you code?

Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice (If
it is, why ANSI atoi doesn't do it)?

There is no way to check the result of atoi, that's why it's better to
use strtol in most situations.

I did not just mean check the return code from a function call.

Especially, I'm asking how to do complicated error check neatly.

[Richard Heathfield]

[e-mail] said:

Do you check all error conditions for all library calls in you code?

It has been said that you should never check for a condition you don't know
how to handle. But apart from that, check everything.

Is it necessary to check all errors?

Is it useful to know whether your program worked? If not, then the program
itself is probably not all that useful.

The following code from net-snmp library calls atoi five times but
checks none.

Feel free to explain how you'd check atoi. Once you've failed to do that,
you will be in a position to explain why the code is broken.

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

[Ian Collins]

[e-mail] wrote:

On Sep 19, 4:08 pm, Ian Collins <[e-mail]:

>[e-mail] wrote:

>>Do you check all error conditions for all library calls in you code?
Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?
The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice (If
it is, why ANSI atoi doesn't do it)?

There is no way to check the result of atoi, that's why it's better to
use strtol in most situations.

I did not just mean check the return code from a function call.

Especially, I'm asking how to do complicated error check neatly.

Use a language with exceptions :)

--
Ian Collins.

[lovecreatesbea...]

On Sep 19, 4:08*pm, Ian Collins <[e-mail]:

[e-mail] wrote:

Do you check all error conditions for all library calls in you code?

Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice (If
it is, why ANSI atoi doesn't do it)?

There is no way to check the result of atoi, that's why it's better to
use strtol in most situations.

I ever thought there're errno for atoi also. Thanks for reminder.

[Nick Keighley]

On 19 Sep, 09:16, "[e-mail]"
<[e-mail]:

On Sep 19, 4:08 pm, Ian Collins <[e-mail]:

[e-mail] wrote:

Do you check all error conditions for all library calls in you code?

Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice (If
it is, why ANSI atoi doesn't do it)?

There is no way to check the result of atoi, that's why it's better to
use strtol in most situations.

I did not just mean check the return code from a function call.

Especially, I'm asking how to do complicated error check neatly.

as someone else suggested, use exceptions.

Out of interest I've coded simple TCP/IP applications
in both C and Python. The Python versions were shorter
and easier to follow.

I somtimes use an exception like style in C

Rv read_box (Db_handle dbh, Box* box, Box_id box_id)
{
Rv rv;
int i;

for (i = 1; i < SHELF_COUNT; i++)
{
if ((rv = read_shelf (dbh, box->shelf[i], box_id, i)) != OK)
return rv;
}

return OK;
}

This was wrappered in macros so the code looked more like:

Rv read_box (Db_handle dbh, Box* box, Box_id box_id)
{
int i;

for (i = 1; i < SHELF_COUNT; i++)
{
read_shelf (dbh, box->shelf[i], box_id, i);
CHECK_ERROR;
}

return OK;
}

It was reasonably easy to follow and reasonably
easy to verify that all the error checking was done.
--
Nick Keighley

"Object-oriented programming is an exceptionally bad idea
that could only have originated in California."
Dijkstra

[lovecreatesbea...]

On Sep 19, 4:28 pm, Richard Heathfield <[e-mail]:

[e-mail] said:

Do you check all error conditions for all library calls in you code?

It has been said that you should never check for a condition you don't know
how to handle. But apart from that, check everything.

Sometimes, I omit some error check to come up with a can-work module
rapidly. Those error code will be supplied after some bug report
thrown out. This approach helps to catch up the schedule.

Is it necessary to check all errors?

Is it useful to know whether your program worked? If not, then the program
itself is probably not all that useful.

Thanks for being patient.

The following code from net-snmp library calls atoi five times but
checks none.

Feel free to explain how you'd check atoi. Once you've failed to do that,
you will be in a position to explain why the code is broken.

That snippet is radomly selected. They even do not check the malloc
for three times, see Line 55, 59 and 64 below.

Dude, was it you who wrote atoi piece plus this one?
/* <quote file=../net-snmp-5.4.1.1/agent/auto_nlist.c*/
34 long
35 auto_nlist_value(const char *string)
36 {
37 struct autonlist **ptr, *it = 0;
38 int cmp;
39
40 if (string == 0)
41 return 0;
42
43 ptr = &nlists;
44 while (*ptr != 0 && it == 0) {
45 cmp = strcmp((*ptr)->symbol, string);
46 if (cmp == 0)
47 it = *ptr;
48 else if (cmp < 0) {
49 ptr = &((*ptr)->left);
50 } else {
51 ptr = &((*ptr)->right);
52 }
53 }
54 if (*ptr == 0) {
55 *ptr = (struct autonlist *) malloc(sizeof(struct
autonlist));
56 it = *ptr;
57 it->left = 0;
58 it->right = 0;
59 it->symbol = (char *) malloc(strlen(string) + 1);
60 strcpy(it->symbol, string);
61 /*
62 * allocate an extra byte for inclusion of a preceding
'_' later
63 */
64 it->nl[0].n_name = (char *) malloc(strlen(string) +
2);
65 #if defined(aix4) || defined(aix5)
66 strcpy(it->nl[0].n_name, string);
67 #else
68 sprintf(it->nl[0].n_name, "_%s", string);
69 #endif
70 it->nl[1].n_name = 0;
71 init_nlist(it->nl);
72 #if !(defined(aix4) || defined(aix5))
73 if (it->nl[0].n_type == 0) {
74 strcpy(it->nl[0].n_name, string);
75 init_nlist(it->nl);
76 }
77 #endif
78 if (it->nl[0].n_type == 0) {
79 if (!
netsnmp_ds_get_boolean(NETSNMP_DS_APPLICATION_ID,
80
NETSNMP_DS_AGENT_NO_ROOT_ACCESS)) {
81 snmp_log(LOG_ERR, "nlist err: neither %s nor _
%s found.\n",
82 string, string);
83 }
84 return (-1);
85 } else {
86 DEBUGMSGTL(("auto_nlist:auto_nlist_value", "found
symbol %s at %x.\n",
87 it->symbol, it->nl[0].n_value));
88 return (it->nl[0].n_value);
89 }
90 } else
91 return (it->nl[0].n_value);
92 }

/* </quote*/

[Nick Keighley]

On 19 Sep, 09:54, "[e-mail]"
<[e-mail]:

On Sep 19, 4:28 pm, Richard Heathfield <[e-mail]:

[e-mail] said:

Do you check all error conditions for all library calls in you code?

It has been said that you should never check for a condition you don't know
how to handle. But apart from that, check everything.

Sometimes, I omit some error check to come up with a can-work module
rapidly. Those error code will be supplied after some bug report
thrown out. This approach helps to catch up the schedule.

not in my experience! I'd much rather put the checks in at the
beginning.
And if you had the checks you wouldn't need to debug- your program
would tell you what was wrong.

<snip>

--
Nick Keighley

[lovecreatesbea...]

On Sep 19, 5:19*pm, Nick Keighley <[e-mail]>
wrote:

On 19 Sep, 09:54, "[e-mail]"

<[e-mail]:

On Sep 19, 4:28 pm, Richard Heathfield <[e-mail]:

[e-mail] said:
Do you check all error conditions for all library calls in you code?

It has been said that you should never check for a condition you don't know
how to handle. But apart from that, check everything.

Sometimes, I omit some error check to come up with a can-work module
rapidly. Those error code will be supplied after some bug report
thrown out. This approach helps to catch up the schedule.

not in my experience! I'd much rather put the checks in at the
beginning.
And if you had the checks you wouldn't need to debug- your program
would tell you what was wrong.

Yes, your way is right way.

[James Kuyper]

[e-mail] wrote:

On Sep 19, 4:28 pm, Richard Heathfield <[e-mail]:

>[e-mail] said:

....

Sometimes, I omit some error check to come up with a can-work module
rapidly. Those error code will be supplied after some bug report
thrown out. This approach helps to catch up the schedule.

Only in the short term (and not even necessarily in the short term). In
the long run, you'll spend more time dealing with the bug reports and
fixing the problem than it would have taken to do it right in the first
place. Even in the short term, there's a good chance that your can-work
module won't work, and that you'll end up missing your schedule anyway
because of a bug that would have been much easier to track down if you'd
included proper error checking in the first place.

For many years, I held the opinion that if I adequately warn my boss of
the danger of skipping testing for errors, I've met my responsibilities.
If he responds by ordering me to go ahead and skip testing despite those
dangers, anything that goes wrong because of that is his responsibility,
not mine. I quickly learned, the hard way, that if I want to take that
attitude, I should always insist on getting such orders in writing. It
took me much longer to learn (again, the hard way) that I should never
obey such orders, period. I don't refuse the orders, I just ignore them.

[James Kuyper]

[e-mail] wrote:

Do you check all error conditions for all library calls in you code?

For any function call that can fail, I make sure that my code is written
to deal with the possibility that it did fail. That usually means
checking for failure with every function call. However, for things like
writing to a stream, I can do a lot of function calls that write to the
file, and then use ferror() once to see if any of them failed. I almost
never check the return value of printf(), for precisely this reason.

What makes that approach feasible is the fact that, for my typical
program, it doesn't matter much which write to the stream failed; if any
of them failed, it's a fatal error, and there's only a minor cost to
failing late rather than failing immediately. For many people's
programs, that is not true - when writing to a pipe or writing to a
device, it's sometimes important to react immediately to any failure.

This approach is NOT appropriate when reading data from a stream. If the
data was not read in, the contents of the buffer I read it into are
unpredictable, and almost certainly not what the rest of my code expects
it to be. I need to choose an alternate path through my code as soon as
I detect the error.

Is it necessary to check all errors?

No, but it's needed more often than some lazy programmers think it is.
In the long run, it's easier to make a habit of checking every call that
could fail, than to try to figure out for each call whether or not it
really needs to be checked. If you follow the second approach, you'll
almost certainly find yourself debugging a mysterious error that will
end up tracing back to the unnoticed failure of a function call.

... Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

No, it is not convenient. There's a real danger of making your code look
like it's main purpose is to produce error messages. I once had a
subordinate who handed me a test plan for a function which triggered
every single error message the function could generate, but which didn't
have even a single test case that didn't generate an error message. His
test plan didn't bother checking whether the program actually performed
the task it was supposed to perform when given non-erroneous input!

[Richard Heathfield]

James Kuyper said:

[e-mail] wrote:

>Do you check all error conditions for all library calls in you code?

For any function call that can fail, I make sure that my code is written
to deal with the possibility that it did fail. That usually means
checking for failure with every function call. However, for things like
writing to a stream, I can do a lot of function calls that write to the
file, and then use ferror() once to see if any of them failed. I almost
never check the return value of printf(), for precisely this reason.

Absolutely - BUT.

But there comes a point of diminishing returns. Let's say you're trying to
write an error message in a dialog box, and the call to display the box
returns an error, which you intercept. Okay, now you have to log it
somewhere else. Let's try stderr! Great - except that the fprintf fails.
Now what do you do?

One might reasonably argue that if we can't even report errors to the user,
the system is so far gone that the only reasonable thing to do is close
the program, returning EXIT_FAILURE as a last ditch effort to be diligent.

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

[pete]

[e-mail] wrote:

Do you check all error conditions for all library calls in you code?

Not if I don't have any alternative action that I want to perform.
If printf("hello world\n") returns EOF,
then I really don't have any alternative action for that.

--
pete

[James Kuyper]

pete wrote:

[e-mail] wrote:

>Do you check all error conditions for all library calls in you code?

Not if I don't have any alternative action that I want to perform.
If printf("hello world\n") returns EOF,
then I really don't have any alternative action for that.

Even if all other modes of reporting an error are shut down, you can
always exit with an exit status of EXIT_FAILURE. That method of
reporting might be disabled too, but there's no way from within portable
code to determine that, so you might as well try.

[Richard Tobin]

In article <bA*************@nwrddc02.gnilink.net>,
James Kuyper <ja*********@verizon.netwrote:

>Even if all other modes of reporting an error are shut down, you can
always exit with an exit status of EXIT_FAILURE.

What if exit() unexpectedly returns?

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Richard Heathfield]

Richard Tobin said:

In article <bA*************@nwrddc02.gnilink.net>,
James Kuyper <ja*********@verizon.netwrote:

>>Even if all other modes of reporting an error are shut down, you can
always exit with an exit status of EXIT_FAILURE.

What if exit() unexpectedly returns?

Call it again. In fact, call it in a loop. The program is bound to notice
eventually.

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

[Andrew Poelstra]

On 2008-09-19, [e-mail] <lo***************@gmail.comwrote:

On Sep 19, 4:08 pm, Ian Collins <[e-mail]:

>[e-mail] wrote:

Do you check all error conditions for all library calls in you code?

Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice (If
it is, why ANSI atoi doesn't do it)?

There is no way to check the result of atoi, that's why it's better to
use strtol in most situations.

I did not just mean check the return code from a function call.

Especially, I'm asking how to do complicated error check neatly.

I use goto.

if(!(mem1 = malloc(sizeof *mem1)) ||
!(mem2 = malloc(sizeof *mem2)) ||
!(mem3 = malloc(sizeof *mem3)))
{
err_code = OUT_OF_MEMORY;
goto fail;
}

if(!(infile = fopen("./in.txt", "r")) ||
!(outfile = fopen("./out.txt", "w")))
{
err_code = FILE_ERROR;
goto fail;
}

/* logic below */

return 0;

fail:
free(mem1); /* These would be initialized to NULL
free(mem2); in case their malloc() or fopen()
free(mem3); never gets called. */
fclose(infile);
fclose(outfile);
return err_code;

--
Andrew Poelstra ap*******@wpsoftware.net
That was a joke. Jokes in mathematics, are sometimes not funny.
-Veselin Jungic

[CBFalconer]

"[e-mail]" wrote:

>
Do you check all error conditions for all library calls in you code?

Is it necessary to check all errors? Is it convenient to check all
errors (or how to make code clean and readable with mass of non
business logic related code block)?

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice
(If it is, why ANSI atoi doesn't do it)?

Don't use atoi. Use one of strtod, strtold, strtou, which have
good error detection facilities. atoi is only there to handle old
code, written before the strto functions were available.

atoi doesn't do it because revising it would strand the old
software.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Tobin]

In article <u_******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>What if exit() unexpectedly returns?

>Call it again. In fact, call it in a loop. The program is bound to notice
eventually.

What if the loop unexpectedly terminates... oh never mind.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[James Kuyper]

Richard Tobin wrote:

In article <bA*************@nwrddc02.gnilink.net>,
James Kuyper <ja*********@verizon.netwrote:

>Even if all other modes of reporting an error are shut down, you can
always exit with an exit status of EXIT_FAILURE.

What if exit() unexpectedly returns?

I'd expect a smiley on such a statement. In the absence of one, I'll
treat it seriously. Many of the standard library routines are defined in
a way that allows them to fail even if used perfectly correctly, and
provide mechanisms whereby such failures can be detected. Those
mechanisms should be used. However,

7.20.4.3p6: "The exit function cannot return to its caller."

The possibility of exit() returning to its caller is not worth worrying
about.

I won't say it can't happen, but worrying about the possibility is no
more reasonable than worrying about the possibility that any other
feature of C has been implemented incorrectly.

[Ben Bacarisse]

Andrew Poelstra <ap*******@supernova.homewrites:
,snip>

I use goto.

if(!(mem1 = malloc(sizeof *mem1)) ||
!(mem2 = malloc(sizeof *mem2)) ||
!(mem3 = malloc(sizeof *mem3)))
{
err_code = OUT_OF_MEMORY;
goto fail;
}

if(!(infile = fopen("./in.txt", "r")) ||
!(outfile = fopen("./out.txt", "w")))
{
err_code = FILE_ERROR;
goto fail;
}

/* logic below */

return 0;

fail:
free(mem1); /* These would be initialized to NULL
free(mem2); in case their malloc() or fopen()
free(mem3); never gets called. */
fclose(infile);
fclose(outfile);

fclose(NULL) is undefined. These two need to be protected with an if
each. Such a shame that there is no symmetry with malloc/free but
that is how the world is!

return err_code;

--
Ben.

[lovecreatesbea...]

Thanks Ian and Richard for mentioning the weakness of atoi also.

On Sep 19, 9:28*pm, CBFalconer <[e-mail]:

"[e-mail]" wrote:

The following code from net-snmp library calls atoi five times but
checks none. Do we code a wrapper my_atoi_with_error_check() around
atoi and call this new one everywhere else? Is it a good practice
(If it is, why ANSI atoi doesn't do it)?

Don't use atoi. *Use one of strtod, strtold, strtou, which have
good error detection facilities. *atoi is only there to handle old
code, written before the strto functions were available.

atoi doesn't do it because revising it would strand the old
software.

Yes, thanks for this information.

[Richard Heathfield]

Richard Tobin said:

In article <u_******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>What if exit() unexpectedly returns?

>>Call it again. In fact, call it in a loop. The program is bound to notice
eventually.

What if the loop unexpectedly terminates...

Use recursion (duh!):

#include <stdlib.h>

int finished(int);

int finish(int status)
{
do
{
exit(status);
finished(status);
} while(!finish(status));
return 0;
}

int finished(int status)
{
do
{
finish(status);
exit(status);
}
while(!finished(status));
return 0;
}

In next week's issue: The Halting Problem Revisited.

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

[lovecreatesbea...]

On Sep 19, 6:32 pm, James Kuyper <[e-mail]:

[e-mail] wrote:

On Sep 19, 4:28 pm, Richard Heathfield <[e-mail]:

[e-mail] said:

...

Sometimes, I omit some error check to come up with a can-work module
rapidly. Those error code will be supplied after some bug report
thrown out. This approach helps to catch up the schedule.

Only in the short term (and not even necessarily in the short term). In
the long run, you'll spend more time dealing with the bug reports and
fixing the problem than it would have taken to do it right in the first
place. Even in the short term, there's a good chance that your can-work
module won't work, and that you'll end up missing your schedule anyway
because of a bug that would have been much easier to track down if you'd
included proper error checking in the first place.

For many years, I held the opinion that if I adequately warn my boss of
the danger of skipping testing for errors, I've met my responsibilities.
If he responds by ordering me to go ahead and skip testing despite those
dangers, anything that goes wrong because of that is his responsibility,
not mine. I quickly learned, the hard way, that if I want to take that
attitude, I should always insist on getting such orders in writing. It
took me much longer to learn (again, the hard way) that I should never
obey such orders, period. I don't refuse the orders, I just ignore them.

(My boss and ex-bosses don't know about C programming and don't care
about C programming. I'm supposed to show them some instant
achievement same as other humble programmers in China do. My bosses do
the same instant things to the clients.)

Thanks you for the advice, it helps me.

[CBFalconer]

Richard Heathfield wrote:

Richard Tobin said:

>James Kuyper <ja*********@verizon.netwrote:

>>Even if all other modes of reporting an error are shut down,
you can always exit with an exit status of EXIT_FAILURE.

What if exit() unexpectedly returns?

Call it again. In fact, call it in a loop. The program is bound
to notice eventually.

If exit returns complain to the C system supplier. It is faulty.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>Richard Tobin said:

>>James Kuyper <ja*********@verizon.netwrote:

Even if all other modes of reporting an error are shut down,
you can always exit with an exit status of EXIT_FAILURE.

What if exit() unexpectedly returns?

Call it again. In fact, call it in a loop. The program is bound
to notice eventually.

If exit returns complain to the C system supplier. It is faulty.

Whoosh!

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

[christian.bau]

On Sep 19, 3:52*pm, "[e-mail]"
<[e-mail]:

(My boss and ex-bosses don't know about C programming and don't care
about C programming. I'm supposed to show them some instant
achievement same as other humble programmers in China do. My bosses do
the same instant things to the clients.)

Whose money is lost if you do shoddy work by following your bosses
orders? If it's your bosses money, go ahead. If it's not your bosses
money, follow your conscience.

[Richard Heathfield]

christian.bau said:

On Sep 19, 3:52 pm, "[e-mail]"
<[e-mail]:

>(My boss and ex-bosses don't know about C programming and don't care
about C programming. I'm supposed to show them some instant
achievement same as other humble programmers in China do. My bosses do
the same instant things to the clients.)

Whose money is lost if you do shoddy work by following your bosses
orders?

Yours, if you lose your job when the company goes bust after its flagship
product crashes and burns because you wrote shoddy code despite knowing
better.

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

[lovecreatesbea...]

On Sep 19, 10:26 pm, Ben Bacarisse <[e-mail]:

Andrew Poelstra <[e-mail]:

if(!(mem1 = malloc(sizeof *mem1)) ||
!(mem2 = malloc(sizeof *mem2)) ||
!(mem3 = malloc(sizeof *mem3)))
{
err_code = OUT_OF_MEMORY;
goto fail;
}

if(!(infile = fopen("./in.txt", "r")) ||
!(outfile = fopen("./out.txt", "w")))
{
err_code = FILE_ERROR;
goto fail;
}

/* logic below */

return 0;

fail:
free(mem1); /* These would be initialized to NULL
free(mem2); in case their malloc() or fopen()
free(mem3); never gets called. */
fclose(infile);
fclose(outfile);

fclose(NULL) is undefined. These two need to be protected with an if
each.

or better return or exit earlier when a null returned upon fopen.

Such a shame that there is no symmetry with malloc/free but
that is how the world is!

I think the sequence of calls to malloc/free is fine provide NULL
initialization performed before malloc.

[lovecreatesbea...]

On Sep 19, 11:40 pm, Richard Heathfield <[e-mail]:

christian.bau said:

On Sep 19, 3:52 pm, "[e-mail]"
<[e-mail]:

(My boss and ex-bosses don't know about C programming and don't care
about C programming. I'm supposed to show them some instant
achievement same as other humble programmers in China do. My bosses do
the same instant things to the clients.)

Whose money is lost if you do shoddy work by following your bosses
orders?

Yours, if you lose your job when the company goes bust after its flagship
product crashes and burns because you wrote shoddy code despite knowing
better.

Aren't there lots of buggy flagship products all around the world?

[Richard Heathfield]

[e-mail] said:

On Sep 19, 11:40 pm, Richard Heathfield <[e-mail]:

>christian.bau said:

<snip>

>>

Whose money is lost if you do shoddy work by following your bosses
orders?

Yours, if you lose your job when the company goes bust after its
flagship product crashes and burns because you wrote shoddy code despite
knowing better.

Aren't there lots of buggy flagship products all around the world?

Yes. The fact that a product has bugs is, however, no guarantee of success.

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

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

[e-mail] said:

[...]

>The following code from net-snmp library calls atoi five times but
checks none.

Feel free to explain how you'd check atoi. Once you've failed to do that,
you will be in a position to explain why the code is broken.

Conceivably the code doesn't need to differentiate between a string
representing 0 and a string that doesn't represent any integer value,
and whatever code calls it will treat either as an error. Or perhaps
the string being passed to atoi() has been pre-checked and the code we
were shown, in context, can never be called with invalid data. It's
not entirely impossible to use atoi() in non-broken code.

It's more likely, though, that the code is indeed buggy.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

"[e-mail]" <lo***************@gmail.comwrites:

On Sep 19, 10:26 pm, Ben Bacarisse <[e-mail]:

>Andrew Poelstra <[e-mail]:

<snip>

fail:
free(mem1); /* These would be initialized to NULL
free(mem2); in case their malloc() or fopen()
free(mem3); never gets called. */
fclose(infile);
fclose(outfile);

fclose(NULL) is undefined. These two need to be protected with an if
each.

or better return or exit earlier when a null returned upon fopen.

OK, but then you have to free the mem pointers in two places and you
don't get single-entry single-exit functions.

--
Ben.

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>[e-mail] said:

[...]

>>The following code from net-snmp library calls atoi five times but
checks none.

Feel free to explain how you'd check atoi. Once you've failed to do
that, you will be in a position to explain why the code is broken.

Conceivably the code doesn't need to differentiate between a string
representing 0 and a string that doesn't represent any integer value,
and whatever code calls it will treat either as an error.

Whilst 0 is a common return value for atoi when its input can't be
represented as an int, the Standard doesn't mandate this, so code that
relies on it is broken.

Or perhaps
the string being passed to atoi() has been pre-checked and the code we
were shown, in context, can never be called with invalid data.

Right - I had overlooked that possibility.

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

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Keith Thompson said:

[...]

>Conceivably the code doesn't need to differentiate between a string
representing 0 and a string that doesn't represent any integer value,
and whatever code calls it will treat either as an error.

Whilst 0 is a common return value for atoi when its input can't be
represented as an int, the Standard doesn't mandate this, so code that
relies on it is broken.

[...]

Good point; I hadn't realized that.

The following is a paraphrase of C99 7.20.1.2 (dropping the references
to atol and atoll for simplicity):

Description

The atoi function converts the initial portion of the string
pointed to by nptr to int representation. Except for the behavior
on error, it is equivalent to
(int)strtol(nptr, (char**)NULL, 10)

Returns

The atoi function returns the converted value.

And a paraphrase from C99 7.20.1.4:

The strtol function returns the converted value, if any. If no
conversion could be performed, zero is returned.

Until a moment ago, I assumed that the *intent* was that atoi()
returns 0 on error, and the standard just didn't express that intent
properly. But that intent could have been expressed simply by
dropping the phrase "Except for the behavior on error". Since it
doesn't say what the behavior on error *is*, the behavior is
undefined.

A side note: Yes, the (char**) cast on the second argument to strtol
in the definition of atoi is necessary. Even in C99, it's still legal
(though unwise) to call strtol without a visible prototype:

/* no #include <stdlib.h*/
long int strtol();

strtol(nptr, NULL, 0); /* UB */

Here NULL is not of type char**, and it won't be converted to char**,
causing undefined behavior.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[vippstar]

On Sep 19, 7:51 pm, Keith Thompson <[e-mail]:

Richard Heathfield <[e-mail]:

Keith Thompson said:

[...]

Conceivably the code doesn't need to differentiate between a string
representing 0 and a string that doesn't represent any integer value,
and whatever code calls it will treat either as an error.

Whilst 0 is a common return value for atoi when its input can't be
represented as an int, the Standard doesn't mandate this, so code that
relies on it is broken.

[...]

Good point; I hadn't realized that.

The following is a paraphrase of C99 7.20.1.2 (dropping the references
to atol and atoll for simplicity):

Description

The atoi function converts the initial portion of the string
pointed to by nptr to int representation. Except for the behavior
on error, it is equivalent to
(int)strtol(nptr, (char**)NULL, 10)

Returns

The atoi function returns the converted value.

And a paraphrase from C99 7.20.1.4:

The strtol function returns the converted value, if any. If no
conversion could be performed, zero is returned.

Until a moment ago, I assumed that the *intent* was that atoi()
returns 0 on error, and the standard just didn't express that intent
properly. But that intent could have been expressed simply by
dropping the phrase "Except for the behavior on error". Since it
doesn't say what the behavior on error *is*, the behavior is
undefined.

I believe the "behavior on error" is when the string is not an
integer.
strtol can not invoke undefined behavior. If atoi is equal to that
strtol call, it can't invoke undefined behavior if strtol returns 0.
It will invoke implementation defined behavior or will raise
implementation defined signal (only in C99) if the value returned by
strtol is < INT_MIN or INT_MAX.

A side note: Yes, the (char**) cast on the second argument to strtol
in the definition of atoi is necessary. Even in C99, it's still legal
(though unwise) to call strtol without a visible prototype:

/* no #include <stdlib.h*/
long int strtol();

strtol(nptr, NULL, 0); /* UB */

Here NULL is not of type char**, and it won't be converted to char**,
causing undefined behavior.

Ah thanks, this bugged me for some time.

[CBFalconer]

"[e-mail]" wrote:

Ben Bacarisse <[e-mail]:

>Andrew Poelstra <[e-mail]:

>>if(!(mem1 = malloc(sizeof *mem1)) ||
!(mem2 = malloc(sizeof *mem2)) ||
!(mem3 = malloc(sizeof *mem3))) {
err_code = OUT_OF_MEMORY;
goto fail;
}
if (!(infile = fopen("./in.txt", "r")) ||
!(outfile = fopen("./out.txt", "w"))) {
err_code = FILE_ERROR;
goto fail;
}
/* logic below */
return 0;

fail:
free(mem1); /* These would be initialized to NULL */
free(mem2); /* in case their malloc() or fopen() */
free(mem3); /* never gets called. */
fclose(infile);
fclose(outfile);

fclose(NULL) is undefined. These two need to be protected with
an if each.

or better return or exit earlier when a null returned upon fopen.

>Such a shame that there is no symmetry with malloc/free but
that is how the world is!

I think the sequence of calls to malloc/free is fine provide NULL
initialization performed before malloc.

fclose(outfile) can be called with an uninitialized outfile in the
above. So besides protecting by detecting NULL value, you need to
initialized them to NULL.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Ben Bacarisse wrote:

"[e-mail]" <lo***************@gmail.comwrites:

>Ben Bacarisse <[e-mail]:

>>Andrew Poelstra <[e-mail]:

<snip>

>>>fail:
free(mem1); /* These would be initialized to NULL
free(mem2); in case their malloc() or fopen()
free(mem3); never gets called. */
fclose(infile);
fclose(outfile);

fclose(NULL) is undefined. These two need to be protected with an if
each.

or better return or exit earlier when a null returned upon fopen.

OK, but then you have to free the mem pointers in two places and you
don't get single-entry single-exit functions.

Simply use: if (f) fclose(f);
(assuming no error test on fclose is needed).

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

"christian.bau" wrote:

<[e-mail]:

>(My boss and ex-bosses don't know about C programming and don't
care about C programming. I'm supposed to show them some instant
achievement same as other humble programmers in China do. My
bosses do the same instant things to the clients.)

Whose money is lost if you do shoddy work by following your
bosses orders? If it's your bosses money, go ahead. If it's not
your bosses money, follow your conscience.

Not wise. When the problems arise, who gets blamed and loses
reputation? Just do a proper job in the first place.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ben Bacarisse]

CBFalconer <cb********@yahoo.comwrites:

Ben Bacarisse wrote:

>"[e-mail]" <lo***************@gmail.comwrites:

>>Ben Bacarisse <[e-mail]:
Andrew Poelstra <[e-mail]:

<snip>

>>>>fail:
free(mem1); /* These would be initialized to NULL
free(mem2); in case their malloc() or fopen()
free(mem3); never gets called. */
fclose(infile);
fclose(outfile);

fclose(NULL) is undefined. These two need to be protected with an if
each.

or better return or exit earlier when a null returned upon fopen.

OK, but then you have to free the mem pointers in two places and you
don't get single-entry single-exit functions.

Simply use: if (f) fclose(f);
(assuming no error test on fclose is needed).

Isn't that what I said?

--
Ben.

[Richard Heathfield]

Ben Bacarisse said:

CBFalconer <cb********@yahoo.comwrites:

>Ben Bacarisse wrote:

>>"[e-mail]" <lo***************@gmail.comwrites:
Ben Bacarisse <[e-mail]:
Andrew Poelstra <[e-mail]:

<snip>

>>>>> fclose(infile);
> fclose(outfile);
>
fclose(NULL) is undefined. These two need to be protected with an if
each.

or better return or exit earlier when a null returned upon fopen.

OK, but then you have to free the mem pointers in two places and you
don't get single-entry single-exit functions.

Simply use: if (f) fclose(f);
(assuming no error test on fclose is needed).

Isn't that what I said?

Yes.

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

[CBFalconer]

Ben Bacarisse wrote:

CBFalconer <cb********@yahoo.comwrites:

>Ben Bacarisse wrote:

>>"[e-mail]" <lo***************@gmail.comwrites:
Ben Bacarisse <[e-mail]:
Andrew Poelstra <[e-mail]:
<snip>
>fail:
> free(mem1); /* These would be initialized to NULL
> free(mem2); in case their malloc() or fopen()
> free(mem3); never gets called. */
> fclose(infile);
> fclose(outfile);
>
fclose(NULL) is undefined. These two need to be protected with an if
each.

or better return or exit earlier when a null returned upon fopen.

OK, but then you have to free the mem pointers in two places and you
don't get single-entry single-exit functions.

Simply use: if (f) fclose(f);
(assuming no error test on fclose is needed).

Isn't that what I said?

Yes. I think I meant to point out that the original code could
leave outfile uninitialized, so that was also needed. I then
forgot about it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Tobin]

In article <48***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>>> free(mem1); /* These would be initialized to NULL */
free(mem2); /* in case their malloc() or fopen() */
free(mem3); /* never gets called. */
fclose(infile);
fclose(outfile);

>fclose(outfile) can be called with an uninitialized outfile in the
above. So besides protecting by detecting NULL value, you need to
initialized them to NULL.

As mentioned in the comment you quoted.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[christian.bau]

On Sep 19, 9:21*pm, CBFalconer <[e-mail]:

"christian.bau" wrote:

<[e-mail]:

(My boss and ex-bosses don't know about C programming and don't
care about C programming. I'm supposed to show them some instant
achievement same as other humble programmers in China do. My
bosses do the same instant things to the clients.)

Whose money is lost if you do shoddy work by following your
bosses orders? If it's your bosses money, go ahead. If it's not
your bosses money, follow your conscience.

Not wise. *When the problems arise, who gets blamed and loses
reputation? *Just do a proper job in the first place.

The way the original poster described it, what you or I would call
"doing a proper job" is not what his boss calls "doing a proper job".
He would get blame and lose reputation much earlier, and possibly his
job as well.

[Jack Klein]

On Fri, 19 Sep 2008 10:24:44 -0700 (PDT), vi******@gmail.com wrote in
comp.lang.c:

On Sep 19, 7:51 pm, Keith Thompson <[e-mail]:

Richard Heathfield <[e-mail]:

Keith Thompson said:

[...]

>Conceivably the code doesn't need to differentiate between a string
>representing 0 and a string that doesn't represent any integer value,
>and whatever code calls it will treat either as an error.

Whilst 0 is a common return value for atoi when its input can't be
represented as an int, the Standard doesn't mandate this, so code that
relies on it is broken.

[...]

Good point; I hadn't realized that.

The following is a paraphrase of C99 7.20.1.2 (dropping the references
to atol and atoll for simplicity):

Description

The atoi function converts the initial portion of the string
pointed to by nptr to int representation. Except for the behavior
on error, it is equivalent to
(int)strtol(nptr, (char**)NULL, 10)

Returns

The atoi function returns the converted value.

And a paraphrase from C99 7.20.1.4:

The strtol function returns the converted value, if any. If no
conversion could be performed, zero is returned.

Until a moment ago, I assumed that the *intent* was that atoi()
returns 0 on error, and the standard just didn't express that intent
properly. But that intent could have been expressed simply by
dropping the phrase "Except for the behavior on error". Since it
doesn't say what the behavior on error *is*, the behavior is
undefined.

I believe the "behavior on error" is when the string is not an
integer.
strtol can not invoke undefined behavior. If atoi is equal to that
strtol call, it can't invoke undefined behavior if strtol returns 0.
It will invoke implementation defined behavior or will raise
implementation defined signal (only in C99) if the value returned by
strtol is < INT_MIN or INT_MAX.

You are laboring under a dangerous misunderstanding here.

Here is what C90 says about atoi(), atol(), and atof():

"The functions atof, atoi, and atol need not affect the value of the
integer expression errno on an error. If the value of the result
cannot be represented, the behavior is undefined."

The difference in C99 is that the new function atoll() is included:

"The functions atof, atoi, atol, and atoll need not affect the value
of the integer expression errno on an error. If the value of the
result cannot be represented, the behavior is undefined."

The ato... functions all invoke undefined behavior if the text string
represents a value outside the range of the function's return type. No
implementation-defined behavior or implementation-defined signal, just
plain old UB.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Keith Thompson]

Jack Klein <ja*******@spamcop.netwrites:
[...]

You are laboring under a dangerous misunderstanding here.

Here is what C90 says about atoi(), atol(), and atof():

"The functions atof, atoi, and atol need not affect the value of the
integer expression errno on an error. If the value of the result
cannot be represented, the behavior is undefined."

The difference in C99 is that the new function atoll() is included:

"The functions atof, atoi, atol, and atoll need not affect the value
of the integer expression errno on an error. If the value of the
result cannot be represented, the behavior is undefined."

The ato... functions all invoke undefined behavior if the text string
represents a value outside the range of the function's return type. No
implementation-defined behavior or implementation-defined signal, just
plain old UB.

Argh, how did I miss that?

Or, rather, arrrrrrrrrrgh (this being International Talk Like a Pirate
Day).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

"christian.bau" wrote:

CBFalconer <[e-mail]:

>"christian.bau" wrote:

>><[e-mail]:

(My boss and ex-bosses don't know about C programming and
don't care about C programming. I'm supposed to show them some
instant achievement same as other humble programmers in China
do. My bosses do the same instant things to the clients.)

Whose money is lost if you do shoddy work by following your
bosses orders? If it's your bosses money, go ahead. If it's not
your bosses money, follow your conscience.

Not wise. When the problems arise, who gets blamed and loses
reputation? Just do a proper job in the first place.

The way the original poster described it, what you or I would
call "doing a proper job" is not what his boss calls "doing a
proper job". He would get blame and lose reputation much earlier,
and possibly his job as well.

While there may be exceptions [1] I expect that the 'boss' will
never notice, but both he and the programmer will get the
reputation of producing good code.

[1] Exceptions include such things as embedded packages needing
absolute minimum code space. If the boss ever notices he has to be
a reasonably capable programmer himself, and can probably
appreciate the necessity for those checks.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Jack Klein wrote:

vi******@gmail.com wrote:

.... snip ...

>

>strtol can not invoke undefined behavior. If atoi is equal to
that strtol call, it can't invoke undefined behavior if strtol
returns 0. It will invoke implementation defined behavior or
will raise implementation defined signal (only in C99) if the
value returned by strtol is < INT_MIN or INT_MAX.

You are laboring under a dangerous misunderstanding here.

Here is what C90 says about atoi(), atol(), and atof():

"The functions atof, atoi, and atol need not affect the value
of the integer expression errno on an error. If the value of
the result cannot be represented, the behavior is undefined."

The difference in C99 is that the new function atoll() is
included:

"The functions atof, atoi, atol, and atoll need not affect the
value of the integer expression errno on an error. If the
value of the result cannot be represented, the behavior is
undefined."

The ato... functions all invoke undefined behavior if the text
string represents a value outside the range of the function's
return type. No implementation-defined behavior or
implementation-defined signal, just plain old UB.

I think you are missing the point. Those ato* functions are only
present to allow old code to be compiled. There is no purpose
whatsoever to the atoll code except to encourage foolishness. They
can all be replaced by strto* calls, which have proper error
reporting capabilities, and should be so replaced in any new code.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Jack Klein wrote:

[...]

>The ato... functions all invoke undefined behavior if the text
string represents a value outside the range of the function's
return type. No implementation-defined behavior or
implementation-defined signal, just plain old UB.

I think you are missing the point.

Huh? What makes you think that?

Those ato* functions are only
present to allow old code to be compiled. There is no purpose
whatsoever to the atoll code except to encourage foolishness. They
can all be replaced by strto* calls, which have proper error
reporting capabilities, and should be so replaced in any new code.

He didn't miss the point, he was providing an argument in favor of it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"