linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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-----

  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).