All of lore.kernel.org
 help / color / mirror / Atom feed
From: _z33 <timid.Gentoo@gmail.com>
To: linux-c-programming@vger.kernel.org
Subject: Re: default function parameters
Date: Fri, 09 Sep 2005 12:38:13 -0700	[thread overview]
Message-ID: <dfrc52$rro$1@sea.gmane.org> (raw)
In-Reply-To: <6a00c8d505090823472706ba98@mail.gmail.com>

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

_z33
-- 
I love TUX; well... that's an understatement :)


  reply	other threads:[~2005-09-09 19:38 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 [this message]
2005-09-09  7:36     ` Steve Graegert
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='dfrc52$rro$1@sea.gmane.org' \
    --to=timid.gentoo@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.