From: Jesse Ruffin <jesse@ajp-services.net>
To: linux-c-programming@vger.kernel.org
Subject: Re: Code critique: checking for syntax errors
Date: Mon, 23 Jan 2006 17:37:04 -0500 [thread overview]
Message-ID: <43D55A90.7030501@ajp-services.net> (raw)
In-Reply-To: <43D532D6.9050204@colannino.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Colannino wrote:
| Do stricter and older compilers complain if variables aren't declared at
| the beginning of the function?
| Actually, I was banking on the C99 standard (I guess perhaps it would
| have been wise for me to say so when I posted the code.)
If you are using a C99 compiler it won't, but older C specifications do
not allow variable definition anywhere but the beginning or between the
function declaration and definition (K&R style). Although C99 is gaining
a lot of ground, I believe that there still are some compilers that
don't support it at all, and many that don't by default.
| I can understand EXIT_FAILURE, but why do all the C books tell you to
| return 0 instead of EXIT_SUCCESS? I always thought that both return()
| and exit() did the same basic thing, so I'm confused as to why a book
| teaching how to write portable code would say to simply use 0 (that's
| with return() and not exit().) I have implemented exit(EXIT_FAILURE)
| instead of exit(1).
The man page for exit has this to say about EXIT_*:
| The use of EXIT_SUCCESS and EXIT_FAILURE is slightly more portable (to
| non-Unix environments) than that of 0 and some non-zero value like 1 or
| -1. In particular, VMS uses a different convention.
and the info pages on exit vs. return:
| A process terminates normally when its program signals it is done by
| calling `exit'. Returning from `main' is equivalent to calling `exit',
| and the value that `main' returns is used as the argument to `exit'.
Hope that helps a bit.
Also, #defines are almost always better than hard coded values. If
nothing else they're more readable, and often centralize changes.
Jesse Ruffin
AJP Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD1VqQ8GGeAXLl3osRApXRAJ9k1BzmmmB5prkONd2YDTn064lHewCfcZ5m
S9uAmyjy7LXnYpDmp92H04o=
=l0AT
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2006-01-23 22:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-21 19:10 Code critique: checking for syntax errors James Colannino
2006-01-22 9:34 ` Jesse Ruffin
2006-01-23 19:47 ` James Colannino
2006-01-23 22:37 ` Jesse Ruffin [this message]
2006-01-23 22:59 ` James Colannino
2006-01-24 0:44 ` Jesse Ruffin
2006-01-24 2:06 ` James Colannino
2006-01-24 9:34 ` Glynn Clements
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43D55A90.7030501@ajp-services.net \
--to=jesse@ajp-services.net \
--cc=linux-c-programming@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).