linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Graegert <graegerts@gmail.com>
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Ankit Jain <ankitjain1580@yahoo.com>,
	linux-c-programming@vger.kernel.org
Subject: Re: variable length function
Date: Wed, 15 Jun 2005 08:33:06 +0200	[thread overview]
Message-ID: <6a00c8d50506142333197a5b0@mail.gmail.com> (raw)
In-Reply-To: <17071.37179.269117.890201@gargle.gargle.HOWL>

On 6/15/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> 
> Steve Graegert wrote:
> 
> > > also, if what is the default return type and value of
> > > main function in C in gcc, ansi C and turbo C?
> 
> > Question 4:
> > ISO C99 suggests the return type of main() to be of type int.  There
> > is a never ending debate among some professionals whether void is
> > equally legal.  Some compilers behave like ANSI C that allows
> > declaration of type void but return int implicitly.  In other words:
> > stick to int.
> 
> The value returned from main is used as the process' exit code. If you
> declare main() as returning void, and return from it, the process is
> likely to have a random exit code (e.g. whatever happens to be in the
> EAX register upon return from main()).

Yes, another important issue.  The most reliable way to return a valid
and correct value I am aware of is returning a value explicitly. 
You're right. just declaring int does not imply the return code to be
the expected one, though being valid.  It is __not__ guaranteed that
the return type is not some random integer value unless it is returned
explicitly.

Another point that comes to mind are compilers with distinct calling
conventions for int and void functions and job control for example. 
This can cause headaches when main() does not push a return value on
the stack, as being the case with void, and the caller tries to pop an
int which obviously is not found.  It __may__ lead to subtle crashes
later on.


Kind Regards

    \Steve

--

Steve Graegert <graegerts@gmail.com> || <http://www.technologies.de/~sg/>
Independent Software Consultant {C/C++ && Java && .NET}
Mobile: +49 (176)  21 24 88 69
Office: +49 (9131) 71 26 40 9

  reply	other threads:[~2005-06-15  6:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-14 17:43 variable length function Ankit Jain
2005-06-14 19:14 ` Steve Graegert
2005-06-15  2:23   ` Glynn Clements
2005-06-15  6:33     ` Steve Graegert [this message]
2005-06-15  8:36       ` Ankit Jain
2005-06-15  9:08         ` Steve Graegert
2005-06-15 11:33         ` Glynn Clements
2005-06-15 15:59           ` Ankit Jain
2005-06-15 16:26             ` Steve Graegert
2005-06-15 17:22               ` Ron Michael Khu
2005-06-16  2:31           ` Rajkumar Andrews

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=6a00c8d50506142333197a5b0@mail.gmail.com \
    --to=graegerts@gmail.com \
    --cc=ankitjain1580@yahoo.com \
    --cc=glynn@gclements.plus.com \
    --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).