From: Steve Graegert <graegerts@gmail.com>
To: _z33 <timid.Gentoo@gmail.com>
Cc: linux-c-programming@vger.kernel.org
Subject: Re: default function parameters
Date: Fri, 9 Sep 2005 09:36:28 +0200 [thread overview]
Message-ID: <6a00c8d505090900364f76dcfd@mail.gmail.com> (raw)
In-Reply-To: <dfrc52$rro$1@sea.gmane.org>
On 9/9/05, _z33 <timid.Gentoo@gmail.com> wrote:
> Steve Graegert wrote:
> > On 9/9/05, _z33 <timid.Gentoo@gmail.com> wrote:
> >
> >> I had a wierd doubt today morning. If a function's return type is not
> >>defined, "C" takes it as returning "int". Now, what does it do when I
> >>don't specify the arguments of the function. Something like this -
> >>
> >> void sampleFunc ()
> >> {
> >> /* ... */
> >> }
> >>
> >> Is this equivalent to saying,
> >>
> >> void sampleFunc (void)
> >> {
> >> /* ... */
> >> }
> >
> >
> > Yes, technically both are equivalent. The latter is the new style
> > while the former is the "old" style. But be aware: A function defined
> > using the old style does __not__ establish a prototype, but if a
> > previously declared prototype for that function exists, the parameter
> > declarations in the definition must exactly match those in the
> > prototype after the default argument promotions are applied to the
> > parameters in the definition.
> >
> > Conclusion: avoid mixing old style and prototype style
> > declarations/definition for a given function. It is allowed but not
> > recommended.
>
> I'm clear... but, now wondering why for two days a guy from an R&D
> dept of an MNC is arguing with me, saying that a function with empty
> argument specification implies having implicit "int" type arguments.
> (similar to the implicit assumption of return type of functions to "int"
> when none is specified explicitly).
Unless you're writing a compiler this does not matter. Even if an int
argument in implicitly used it has no meaning to the programmer.
Since void is a well defined type, although an incomplete one, I have
doubts that int is used internally. I simply can't see the rationale
behind that (but I'd be happy to be enlightened). Could you please
try to transport your collegue's argumentation?
Regards
\Steve
--
Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176) 21248869
Office: +49 (9131) 7126409
next prev parent reply other threads:[~2005-09-09 7:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-09 18:43 default function parameters _z33
2005-09-09 6:47 ` Steve Graegert
2005-09-09 19:38 ` _z33
2005-09-09 7:36 ` Steve Graegert [this message]
2005-09-09 8:46 ` _z33
2005-09-09 9:23 ` Jarmo
2005-09-09 9:42 ` Steve Graegert
2005-09-09 9:58 ` _z33
2005-09-09 9:50 ` _z33
2005-09-09 9:34 ` Steve Graegert
2005-09-09 9:44 ` _z33
2005-09-09 10:20 ` Steve Graegert
2005-09-09 13:00 ` Glynn Clements
2005-09-09 12:50 ` Glynn Clements
2005-09-09 12:43 ` Glynn Clements
2005-09-10 5:00 ` _z33
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=6a00c8d505090900364f76dcfd@mail.gmail.com \
--to=graegerts@gmail.com \
--cc=linux-c-programming@vger.kernel.org \
--cc=timid.Gentoo@gmail.com \
/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).