Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1228 > unrolled thread

Is this a prototype or not

Back to article view | Back to comp.std.c

Contents

  Is this a prototype or not jacob navia <jacob@spamsink.net> - 2012-04-09 22:16 +0200
    Re: Is this a prototype or not Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-04-09 23:13 +0100
      Re: Is this a prototype or not Tim Rentsch <txr@alumni.caltech.edu> - 2012-04-09 18:16 -0700
        Re: Is this a prototype or not Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-04-10 02:30 +0100
    Re: Is this a prototype or not Tim Rentsch <txr@alumni.caltech.edu> - 2012-04-09 18:07 -0700
      Re: Is this a prototype or not jacob navia <jacob@spamsink.net> - 2012-04-10 21:11 +0200
        Re: Is this a prototype or not Philip Lantz <prl@canterey.us> - 2012-04-13 00:36 -0700
    Re: Is this a prototype or not Harald van Dijk <haraldvdijk@gmail.com> - 2012-04-10 13:57 -0700
      Re: Is this a prototype or not Nick Bowler <nbowler@draconx.ca> - 2012-08-15 15:56 +0000
        Re: Is this a prototype or not Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 19:07 +0200
          Re: Is this a prototype or not Nick Bowler <nbowler@draconx.ca> - 2012-08-23 19:59 +0000
    Re: Is this a prototype or not Philip Lantz <prl@canterey.us> - 2012-04-13 00:25 -0700
    Re: Is this a prototype or not Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-17 02:49 -0700
      Re: Is this a prototype or not Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-17 03:14 -0700
      Re: Is this a prototype or not Keith Thompson <kst-u@mib.org> - 2012-08-17 13:05 -0700
        Re: Is this a prototype or not Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-18 05:27 -0700

#1228 — Is this a prototype or not

Consider the following code:

int fn()
{
	return fn(56);
}

According to the C99 standard

§6.7.5.3 "Function declarators (including prototypes)"
says in constraint 14:

14 An identifier list declares only the identifiers of the parameters of 
the function. An empty list in a function declarator that is part of a 
definition of that function specifies that the function has no 
parameters. The empty list in a function declarator that is not part of 
a definition of that function specifies that no information about the 
number or types of the parameters is supplied.126)

My reading is that the construct

int fn()

should be considered a prototype because

An empty list in a function declarator that is part of a definition of 
that function specifies that the function has no parameters

Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain 
about the obvious error.

I think that I have a very common bug. What is actually the correct 
interpretation?

Thanks in advance.

Jacob navia

[toc] | [next] | [standalone]

#1229

jacob navia <jacob@spamsink.net> writes:

> Consider the following code:
>
> int fn()
> {
> 	return fn(56);
> }
>
> According to the C99 standard
>
> §6.7.5.3 "Function declarators (including prototypes)"
> says in constraint 14:

It's not a constraint.

> 14 An identifier list declares only the identifiers of the parameters
> of the function. An empty list in a function declarator that is part
> of a definition of that function specifies that the function has no
> parameters. The empty list in a function declarator that is not part
> of a definition of that function specifies that no information about
> the number or types of the parameters is supplied.126)
>
> My reading is that the construct
>
> int fn()
>
> should be considered a prototype because
>
> An empty list in a function declarator that is part of a definition of
> that function specifies that the function has no parameters

It's not a prototype.  I think the context of §6.7.5.3, p14 makes this
clear.  Paragraph 14 is all about non-prototype functions.  It's talking
about the "identifier-list" form of defintion: fn(a, b, c) /* ... */ not
the form with a "parameter-type-list".  Thus fn() is special case of the
class of non-prototype function headers.  The syntax for the other form
-- the one that has a parameter-type-list -- can never permit fn().  It
may not be 100% explicit, but it seems reasonably clear to me.

> Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain
> about the obvious error.

I am not sure there is an obvious error.  There is no certainly no
constraint violation.  I suppose a compiler could complain about the
call on the grounds of there being a redundant argument, but I don't
even think the behaviour is undefined.

> I think that I have a very common bug. What is actually the correct
> interpretation?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1231

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> jacob navia <jacob@spamsink.net> writes:
>
>> Consider the following code:
>>
>> int fn()
>> {
>> 	return fn(56);
>> }
>>
>> According to the C99 standard
>>
>> S6.7.5.3 "Function declarators (including prototypes)"
>> says in constraint 14:
>
> It's not a constraint.
>
>> 14 An identifier list declares only the identifiers of the parameters
>> of the function. An empty list in a function declarator that is part
>> of a definition of that function specifies that the function has no
>> parameters. The empty list in a function declarator that is not part
>> of a definition of that function specifies that no information about
>> the number or types of the parameters is supplied.126)
>>
>> My reading is that the construct
>>
>> int fn()
>>
>> should be considered a prototype because
>>
>> An empty list in a function declarator that is part of a definition of
>> that function specifies that the function has no parameters
>
> It's not a prototype.  I think the context of S6.7.5.3, p14 makes this
> clear.  Paragraph 14 is all about non-prototype functions.  It's talking
> about the "identifier-list" form of defintion: fn(a, b, c) /* ... */ not
> the form with a "parameter-type-list".  Thus fn() is special case of the
> class of non-prototype function headers.  The syntax for the other form
> -- the one that has a parameter-type-list -- can never permit fn().  It
> may not be 100% explicit, but it seems reasonably clear to me.
>
>> Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain
>> about the obvious error.
>
> I am not sure there is an obvious error.  There is no certainly no
> constraint violation.  I suppose a compiler could complain about the
> call on the grounds of there being a redundant argument, but I don't
> even think the behaviour is undefined.

If you were somehow prompted to re-read the third sentence of
6.5.2.2 p6, might you get a different neuronal activation?

[toc] | [prev] | [next] | [standalone]

#1232

Tim Rentsch <txr@alumni.caltech.edu> writes:
<snip>
> If you were somehow prompted to re-read the third sentence of
> 6.5.2.2 p6, might you get a different neuronal activation?

Yes, it would.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1230

jacob navia <jacob@spamsink.net> writes:

> Consider the following code:
>
> int fn()
> {
> 	return fn(56);
> }
>
> According to the C99 standard
>
> S6.7.5.3 "Function declarators (including prototypes)"
> says in constraint 14:
>
> 14 An identifier list declares only the identifiers of the parameters
> of the function. An empty list in a function declarator that is part
> of a definition of that function specifies that the function has no
> parameters. The empty list in a function declarator that is not part
> of a definition of that function specifies that no information about
> the number or types of the parameters is supplied.126)
>
> My reading is that the construct
>
> int fn()
>
> should be considered a prototype because
>
> An empty list in a function declarator that is part of a definition of
> that function specifies that the function has no parameters

This reading is reasonable.  However it doesn't match how these
passages are normally construed.

> Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain
> about the obvious error.
>
> I think that I have a very common bug. What is actually the correct
> interpretation?

The definition of 'fn()' does not provide a prototype.  There are
two ways to think about this:

  1. Although the definition of 'fn()' does specify that the
  /function/ takes no parameters, that specification doesn't
  affect the /type/ of fn().  Because the type is not affected,
  none of the passages that depend on prototypes are triggered
  (they always say something like "defined with a type that
  includes a prototype).  Because the type is not affected,
  there is no prototype.

  2. The wording in 6.2.1p2 is simply slightly wrong.  The
  sentence defining 'function prototype' mentions 'a declaration
  of a function' but what is actually meant is 'a function
  declarator or function abstract declarator'.  For example,
  in a declaration such as

      int (*foo)( int, double );

  most people would say that a function prototype is present
  even though there is no function declaration (the only
  thing being declared is a pointer to function).  It's easy
  to find other examples.  Furthermore, it matters, because
  it affects the consequences of the definition of 'function
  prototype scope'.

However you want to think of it, the general sentiment is
that functions defined like 'fn()' above do not supply a prototype.
(And yes, the Standard is confusingly worded on this topic.)

[toc] | [prev] | [next] | [standalone]

#1233

Le 10/04/12 03:07, Tim Rentsch a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> Consider the following code:
>>
>> int fn()
>> {
>> 	return fn(56);
>> }
>>
>> According to the C99 standard
>>
>> S6.7.5.3 "Function declarators (including prototypes)"
>> says in constraint 14:
>>
>> 14 An identifier list declares only the identifiers of the parameters
>> of the function. An empty list in a function declarator that is part
>> of a definition of that function specifies that the function has no
>> parameters. The empty list in a function declarator that is not part
>> of a definition of that function specifies that no information about
>> the number or types of the parameters is supplied.126)
>>
>> My reading is that the construct
>>
>> int fn()
>>
>> should be considered a prototype because
>>
>> An empty list in a function declarator that is part of a definition of
>> that function specifies that the function has no parameters
>
> This reading is reasonable.  However it doesn't match how these
> passages are normally construed.
>
>> Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain
>> about the obvious error.
>>
>> I think that I have a very common bug. What is actually the correct
>> interpretation?
>
> The definition of 'fn()' does not provide a prototype.  There are
> two ways to think about this:
>
>    1. Although the definition of 'fn()' does specify that the
>    /function/ takes no parameters, that specification doesn't
>    affect the /type/ of fn().

Why would be the type of "fn" remain unaffected by a new specification?

Nowhere is that specified. It is just a supposition from you, a 
supposition that could be right or wrong, nobody knows.

Supposing it is true however, you acknowledge that the specification 
"int fn()" when used in the function specification DOES specify a 
function with NO parameters, so the type of the function is "promoted" 
to "int fn(void)", in prototypes notation.


>    Because the type is not affected,
>    none of the passages that depend on prototypes are triggered
>    (they always say something like "defined with a type that
>    includes a prototype).  Because the type is not affected,
>    there is no prototype.
>

But why would the type remain unaffected by such a specification?

In C++, even if it is not relevant here, a fn() specification *is* 
accepted as equivalent to fn(void).

>    2. The wording in 6.2.1p2 is simply slightly wrong.  The
>    sentence defining 'function prototype' mentions 'a declaration
>    of a function' but what is actually meant is 'a function
>    declarator or function abstract declarator'.

If we start to read "what is actually meant" we will never stop since we 
have to build a mental model of the thinking of committee members and 
intentions. I would rather remain in the scope of WHAT IS ACTUALLY 
WRITTEN...


For example,
>    in a declaration such as
>
>        int (*foo)( int, double );
>
>    most people would say that a function prototype is present
>    even though there is no function declaration (the only
>    thing being declared is a pointer to function).

It is obvious that this is a function pointer prototype.

>    It's easy
>    to find other examples.  Furthermore, it matters, because
>    it affects the consequences of the definition of 'function
>    prototype scope'.
>
> However you want to think of it, the general sentiment is
> that functions defined like 'fn()' above do not supply a prototype.
> (And yes, the Standard is confusingly worded on this topic.)

 From a software engineering point of view I think that this code:

int fn()
{
	return fn(45);
}

is an obvious error that should be signaled to the programmer as such.

[toc] | [prev] | [next] | [standalone]

#1244

jacob navia wrote:
> Tim Rentsch a écrit :
> >    2. The wording in 6.2.1p2 is simply slightly wrong.  The
> >    sentence defining 'function prototype' mentions 'a declaration
> >    of a function' but what is actually meant is 'a function
> >    declarator or function abstract declarator'.
> 
> If we start to read "what is actually meant" we will never stop since we 
> have to build a mental model of the thinking of committee members and 
> intentions. I would rather remain in the scope of WHAT IS ACTUALLY 
> WRITTEN...
> 
> 
> For example,
> >    in a declaration such as
> >
> >        int (*foo)( int, double );
> >
> >    most people would say that a function prototype is present
> >    even though there is no function declaration (the only
> >    thing being declared is a pointer to function).
> 
> It is obvious that this is a function pointer prototype.

How interesting that in the previous paragraph you say that you want to 
follow what is actually written, and here, in the very next paragraph, 
you agree that it is better to follow what is actually meant. (Or, do 
you think that there is a "declaration of a function" in that example?)

>  From a software engineering point of view I think that this code:
> 
> int fn()
> {
> 	return fn(45);
> }
> 
> is an obvious error that should be signaled to the programmer as such.

Sure! You do know that the fact that the standard doesn't require a 
diagnostic doesn't prevent you from issuing one, right?

[toc] | [prev] | [next] | [standalone]

#1236

On Apr 9, 10:16 pm, jacob navia <ja...@spamsink.net> wrote:
> My reading is that the construct
>
> int fn()
>
> should be considered a prototype

The official answer is that that function definition does not provide
a prototype. See http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_317.htm

[toc] | [prev] | [next] | [standalone]

#1473

On Tue, 10 Apr 2012 13:57:27 -0700, Harald van Dijk wrote:

> On Apr 9, 10:16 pm, jacob navia <ja...@spamsink.net> wrote:
>> My reading is that the construct
>>
>> int fn()
>>
>> should be considered a prototype
>
> The official answer is that that function definition does not provide
> a prototype. See http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_317.htm

I think the problem is that what a "function prototype" actually _is_ is
not defined very clearly in the standard.  There is some normative text
that talks about things being function prototypes scattered throughout
the standard.  Here's what I found in N1570:

  (A) C11§6.2.1#2:

      A /function prototype/ is a declaration of a function that
      declares the types of its parameters.

  (B) C11§6.2.7#3:

      ... a function type with a parameter type list (a function
      prototype)

  (C) C11§6.9.1#7

      If the declarator [of a function definition] includes a parameter
      type list, the list also specifies the types of all parameters;
      such a declarator also serves as a function prototype ...

  (D) C11§6.11.6#1

      ... function declarators with empty parentheses (not
      prototype-format type declarators) ...

Since the term "function prototype" appears in italics in (A), this is
the main definition according to C11§3#1.  We'll return to that one
after excluding the other three in the context of the following
definition:

  void foo() { }

The text in (B) says that a function with a parameter type list is a
function prototype -- but as this does not imply the converse (the text
does not exclude other things from being function prototypes) this point
is not relevant to our definition of foo as it does not have a parameter
type list.

Similarly, the text in (C) does not imply the converse, so it is not
relevant to our definition of foo.

(D) does actually say something about foo: it is not a "prototype-format
type declarator".  This is a term that isn't defined anywhere, but it
seems to me like it is referring only to the "new" function declarator
syntax.

So that leaves (A).  According to C11§6.7.6.3#14: "An empty [identifier]
list in a function declarator that is part of a definition of that
function specifies that the function has no parameters."  So our
definition of foo has zero parameters.  Moreover, since foo has zero
parameters, the types of all its parameters are specified vacuously by
this declaration.  So (A) would imply that foo() { } does include a
function prototype.

Of course, existing implementations (and the referenced DR) say that it
does not declare a protoype.  It's therefore unclear to me why the
definition in (A) does not simply say something like:

  A /function prototype/ is a function declaration whose parameters are
  specified by a parameter type list.

[toc] | [prev] | [next] | [standalone]

#1475

Hello,

Am 15.08.2012 17:56, schrieb Nick Bowler:
> Of course, existing implementations (and the referenced DR) say that it
> does not declare a protoype.  It's therefore unclear to me why the
> definition in (A) does not simply say something like:
> 
>   A /function prototype/ is a function declaration whose parameters are
>   specified by a parameter type list.

This would only work if the formal specification of
parameter-type-list would contain the "void" case, which it currently
doesn't seem to do. 6.7.6.3p10 is not clear of which type of "list" it
is talking.

Jens

[toc] | [prev] | [next] | [standalone]

#1595

On Wed, 15 Aug 2012 19:07:46 +0200, Jens Gustedt wrote:
> Am 15.08.2012 17:56, schrieb Nick Bowler:
>> Of course, existing implementations (and the referenced DR) say that it
>> does not declare a protoype.  It's therefore unclear to me why the
>> definition in (A) does not simply say something like:
>> 
>>   A /function prototype/ is a function declaration whose parameters are
>>   specified by a parameter type list.
> 
> This would only work if the formal specification of
> parameter-type-list would contain the "void" case, which it currently
> doesn't seem to do. 6.7.6.3p10 is not clear of which type of "list" it
> is talking.

Well, void is not an identifier after translation phase 7 (6.4.2.1p4),
so void f(void) has a parameter-type-list according to the syntax.

Corollary: 6.7.6.3p10 must be referring to parameter-type-list, since
there is no situation where an identifier-list would contain "an unnamed
parameter of type void".

[toc] | [prev] | [next] | [standalone]

#1243

jacob navia wrote:
> Consider the following code:
> 
> int fn()
> {
> 	return fn(56);
> }
> 
...
> 
> An empty list in a function declarator that is part of a definition of 
> that function specifies that the function has no parameters
> 
> Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain 
> about the obvious error.
> 
> I think that I have a very common bug. What is actually the correct 
> interpretation?

I agree you have a bug. Although there is no constraint violation (as 
shown by other posters), and thus no diagnostic is required by the 
standard, there is an obvious semantic discrepancy, which I think good 
compilers should diagnose. Since yours is intended to be a quality 
compiler, it should issue a diagnostic for this.

Philip

[toc] | [prev] | [next] | [standalone]

#1513

вторник, 10 апреля 2012 г., 0:16:37 UTC+4 пользователь jacob navia написал:
> Consider the following code:
> 
> 
> 
> int fn()
> 
> {
> 
> 	return fn(56);
> 
> }
> 
> 
> 
> According to the C99 standard
> 
> 
> 
> §6.7.5.3 "Function declarators (including prototypes)"
> 
> says in constraint 14:
> 
> 
> 
> 14 An identifier list declares only the identifiers of the parameters of 
> 
> the function. An empty list in a function declarator that is part of a 
> 
> definition of that function specifies that the function has no 
> 
> parameters. The empty list in a function declarator that is not part of 
> 
> a definition of that function specifies that no information about the 
> 
> number or types of the parameters is supplied.126)
> 
> 
> 
> My reading is that the construct
> 
> 
> 
> int fn()
> 
> 
> 
> should be considered a prototype because
> 
> 
> 
> An empty list in a function declarator that is part of a definition of 
> 
> that function specifies that the function has no parameters
> 
> 
> 
> Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain 
> 
> about the obvious error.
> 
> 
> 
> I think that I have a very common bug. What is actually the correct 
> 
> interpretation?
> 
> 
> 
> Thanks in advance.
> 
> 
> 
> Jacob navia

A parameter type list may not be empty. It shall contain at least a single parameter of type void.
A function prototype is a function declaration (without definition) that has a parameter type list. A function prototype defines a prototype scope. A function definition with a parameter type list also serves as a function prototype but it does not define a prototype scope.

[toc] | [prev] | [next] | [standalone]

#1514

пятница, 17 августа 2012 г., 13:49:27 UTC+4 пользователь Vlad from Moscow написал:
> вторник, 10 апреля 2012 г., 0:16:37 UTC+4 пользователь jacob navia написал:
> 
> > Consider the following code:
> 
> > 
> 
> > 
> 
> > 
> 
> > int fn()
> 
> > 
> 
> > {
> 
> > 
> 
> > 	return fn(56);
> 
> > 
> 
> > }
> 
> > 
> 
> > 
> 
> > 
> 
> > According to the C99 standard
> 
> > 
> 
> > 
> 
> > 
> 
> > §6.7.5.3 "Function declarators (including prototypes)"
> 
> > 
> 
> > says in constraint 14:
> 
> > 
> 
> > 
> 
> > 
> 
> > 14 An identifier list declares only the identifiers of the parameters of 
> 
> > 
> 
> > the function. An empty list in a function declarator that is part of a 
> 
> > 
> 
> > definition of that function specifies that the function has no 
> 
> > 
> 
> > parameters. The empty list in a function declarator that is not part of 
> 
> > 
> 
> > a definition of that function specifies that no information about the 
> 
> > 
> 
> > number or types of the parameters is supplied.126)
> 
> > 
> 
> > 
> 
> > 
> 
> > My reading is that the construct
> 
> > 
> 
> > 
> 
> > 
> 
> > int fn()
> 
> > 
> 
> > 
> 
> > 
> 
> > should be considered a prototype because
> 
> > 
> 
> > 
> 
> > 
> 
> > An empty list in a function declarator that is part of a definition of 
> 
> > 
> 
> > that function specifies that the function has no parameters
> 
> > 
> 
> > 
> 
> > 
> 
> > Neither gcc, (with -pedantic -Wall) nor my compiler nor MSVC complain 
> 
> > 
> 
> > about the obvious error.
> 
> > 
> 
> > 
> 
> > 
> 
> > I think that I have a very common bug. What is actually the correct 
> 
> > 
> 
> > interpretation?
> 
> > 
> 
> > 
> 
> > 
> 
> > Thanks in advance.
> 
> > 
> 
> > 
> 
> > 
> 
> > Jacob navia
> 
> 
> 
> A parameter type list may not be empty. It shall contain at least a single parameter of type void.
> 
> A function prototype is a function declaration (without definition) that has a parameter type list. A function prototype defines a prototype scope. A function definition with a parameter type list also serves as a function prototype but it does not define a prototype scope.

I would like to append my previous message.
As it is said in section 5.1.2.2.1 Program startup "The implementation declares no prototype for this function." It means that it is a user who declares the function prototype by means of the function definition with a parameter type list either with a single parameter of type void, or with two parameters, or in implementation defined manner.
This definition serves as a function prototype for other recursive calls of the main.

[toc] | [prev] | [next] | [standalone]

#1517

Vlad from Moscow <vlad.moscow@mail.ru> writes:
[...]
> A parameter type list may not be empty. It shall contain at least a
> single parameter of type void.  A function prototype is a function
> declaration (without definition) that has a parameter type list. A
> function prototype defines a prototype scope. A function definition
> with a parameter type list also serves as a function prototype but it
> does not define a prototype scope.

I agree with what you're saying, but it's not a quotation from
the standard.  Can you support it by citing specific wording in
the standard?

Again, N1370 6.7.6.3p14 says:

    An identifier list declares only the identifiers of the
    parameters of the function. An empty list in a function
    declarator that is part of a definition of that function
    specifies that the function has no parameters. The empty list
    in a function declarator that is not part of a definition of
    that function specifies that no information about the number
    or types of the parameters is supplied.

I'd say that a definition with empty parentheses does *not* provide
a prototype, but it could be argued either way.

    void func0() { /* ...*/ }

specifies that func0 has no parameters.  Similarly, this:

    void func1(n) int n; { /* ... */ }

specifies that func1 has one parameter, but it clearly doesn't provide a
prototype.  The specification that func0 has no parameters applies only
to the function definition, specifically to the existence of the local
variables that are initialized from parameter values on each call.

The whole point is to retain compatibility with pre-ANSI C code, in
which prototypes were not available.  In pre-ANSI C, this:

    void func0() { /* ... */ }

clearly did not provide a prototype, and a call such as func0(42) would
have undefined behavior (to the extent that the concept existed), but
probably would not trigger a diagnostic.

C89 added prototypes to the language as a new feature.  I don't think it
intended to reinterpret existing pre-ANSI programs that didn't have
prototypes, saying that they now have prototypes.

On the other hand, I don't think that a ruling that
    void func0() { /* ... */ }
*does* provide a prototype would cause much harm.  I can't think of
any non-buggy code that would be broken.  And of course compilers
are already free to warn about argument mismatches on calls
to non-prototyped functions, if the information is available.
(gcc doesn't do this; perhaps the developers didn't want to spend
much time supporting non-prototyped functions.)

This contrived program:

void func0() { }

int main(void) {
    if (0) func0(42);
    return 0;
}

is a constraint violation if the definition of func0 provides a
prototype, but is strictly conforming if it doesn't.  I believe
it's strictly conforming (but poor style).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1534

суббота, 18 августа 2012 г., 0:05:15 UTC+4 пользователь Keith Thompson написал:
> I agree with what you're saying, but it's not a quotation from
> 
> the standard.  Can you support it by citing specific wording in
> 
> the standard?
> 
> 
> 

I collected some quotes from the Standard. First of all let consider the grammar

(6.7.6) parameter-type-list:
parameter-list
parameter-list , ...

(6.7.6) parameter-list:
parameter-declaration
parameter-list , parameter-declaration

(6.7.6) parameter-declaration:
declaration-specifiers declarator
declaration-specifiers abstract-declaratoropt

There is not pointed out that parameter declarator is optional. So at least one parameter declaration shall be present.

Further

6.9.1 Function definitions

5 If the declarator includes a parameter type list, the declaration of each parameter shall include an identifier, except for the special case of a parameter list consisting of a single parameter of type void, in which case there shall not be an identifier. No declaration list shall follow.

Here is being said about the special case of a parameter list consisting of a single parameter of type void.

Thie quote can be appended by the following quote

6.7.6.3 Function declarators (including prototypes)
10 The special case of an unnamed parameter of type void as the only item in the list specifies that the function has no parameters.

As for the function prototype:

6.2.1 Scopes of identifiers

2 ...There are four kinds of scopes: function, file, block, and function prototype. (A function prototype is a declaration of a function that declares the types of its parameters.)

4 ...If the declarator or type specifier that declares the identifier appears inside a block or within the list of parameter declarations in a function definition, the identifier has block scope, which terminates at the end of the associated block. If the declarator or type specifier that declares the identifier appears within the list of parameter declarations in a function prototype (not part of a function
definition), the identifier has function prototype scope, which terminates at the end of the function declarator.

Here we see a difference between declaration of a function with a parameter type list and corresponding definition of such a function. In the first case there is a prototype scope while in the second case there is a block scope for identifiers declared in the parameter type list.

Further

6.9.1 Function definitions

7 The declarator in a function definition specifies the name of the function being defined and the identifiers of its parameters. If the declarator includes a parameter type list, the list also specifies the types of all the parameters; such a declarator also serves as a function prototype for later calls to the same function in the same translation unit....

and 

6.2.7 Compatible type and composite type

— If only one type is a function type with a parameter type list (a function prototype), the composite type is a function prototype with the parameter type list.

So any declaration of a function with a parameter type list specifies its prototype. If a declaration of a function is not a definition the same function then it defines prototype scope for its parameters. Otherwise it defines a block scope for its parameters. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web