Re: (part 21) Han from China answers your C questions

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Harald van =?UTF-8?b?RMSzaw==?=

    #16
    Re: (part 21) Han from China answers your C questions

    On Sat, 15 Nov 2008 11:04:03 -0800, Keith Thompson wrote:
    Yes, either "int main(void) { ... }" or "int main() { ... }" defines
    main as taking no parameters; they're similar in that way. But one
    similarity doesn't make them equivalent.
    I'd like to stay out of the main discussion, but I'm curious how you feel
    about this?

    int main(void);
    int main() {
    /* ... */
    }

    Is this equivalent to

    int main(void) {
    /* ... */
    }

    ? If not, in what way are these not equivalent?

    Perhaps also interesting is that

    int main(int argc, char *argv[]) {
    /* ... */
    }

    is not equivalent to

    int main(int argc, char *argv[]);
    int main(argc, argv)
    int argc;
    char *argv[];
    {
    /* ... */
    }

    because the latter allows main to be called as

    int (*mainptr)() = &main;
    (*mainptr)(1u, (char **) 0);

    while the former doesn't, but this doesn't apply to () versus (void).

    Comment

    • pete

      #17
      Re: (part 21) Han from China answers your C questions

      Harald van Dijk wrote:
      On Sat, 15 Nov 2008 07:35:48 -0500, pete wrote:
      >Richard Heathfield wrote:
      >>Ralf Damaschke said:
      >>>s0suk3 wrote:
      >>>>int main(void) { int puts(const char *); puts(" --"); }
      >>>Overkill. No need for a prototype (even in C99).
      >>>>
      >>>int main(void) { int puts(); puts(" --"); }
      >>Overkill. No need for a prototype (even in C99).
      >>>
      >>int main() { int puts(); puts(" --"; }
      >What do you mean by "(even in C99)" ?
      >>
      >There is no implicit function declaration in C99. That's a C89 feature.
      >
      Yes, but unprototyped functions are allowed even in C99.
      I had not noticed the function declaration
      inside of the definition of main, and so
      I missed the whole point of what was being discussed.

      --
      pete

      Comment

      • Ralf Damaschke

        #18
        Re: (part 21) Han from China answers your C questions

        Harald van =?UTF-8?b?RMSzaw==?= wrote:
        On Sat, 15 Nov 2008 07:59:35 +0000, Ralf Damaschke wrote:
        >int main(void) { int puts(); puts(" --"); }
        >
        This doesn't convert the pointer to the string from char * to const
        char *.
        Surprisingly (for me) I am afraid you are right.

        -- Ralf

        Comment

        • Tim Rentsch

          #19
          Re: (part 21) Han from China answers your C questions

          Keith Thompson <kst-u@mib.orgwrites :
          Richard Heathfield <rjh@see.sig.in validwrites:
          Harald van D?k said:

          <snip>
          But if main() isn't equivalent to main(void), and main must be defined as
          int main(void), int main(int argc, char *argv[]), or equivalent, then
          defining it as main() is invalid, even if you don't call main(42). That's
          the point I believe Keith Thompson was making.
          Oh, I see.
          (Personally, I believe int main() is valid.)
          I agree. Note that int main() - in a function *definition* - defines main
          as taking no parameters. The relevant quote is in 3.5.4.3: "An empty list
          in a function declarator that is part of a function definition specifies
          that the function has no parameters. The empty list in a function
          declarator that is not part of a function definition specifies that no
          information about the number or types of the parameters is supplied."

          Almost identical wording appears in 6.7.5.3(14) of C99. Incidentally, the
          wording is slightly tighter in C99 - which is actually quite interesting,
          because it reveals a slight flaw in the wording of the above, but the
          differences aren't relevant to the current case.
          >
          Yes, either "int main(void) { ... }" or "int main() { ... }" defines
          main as taking no parameters; they're similar in that way. But one
          similarity doesn't make them equivalent.
          >
          Here's what the standard says (C99 5.1.2.2.1):
          >
          The function called at program startup is named main. The
          implementation declares no prototype for this function. It shall
          be defined with a return type of int and with no parameters:
          >
          int main(void) { /* ... */ }
          >
          or with two parameters (referred to here as argc and argv, though
          any names may be used, as they are local to the function in which
          they are declared):
          >
          int main(int argc, char *argv[]) { /* ... */ }
          >
          or equivalent; or in some other implementation-defined manner.
          >
          The following two declarations:
          >
          int x;
          double x;
          >
          are similar in that they both declare objects named "x". They're not
          equivalent, though, because they declare objects of different types.
          Even putting them in a program where the difference has no visible
          effect doesn't make them equivalent; the programs might be effectively
          equivalent, but the declarations aren't. (My argument here is just a
          reasonable use of the word "equivalent ".)
          >
          The following two function definitions:
          >
          int main() { return 0; }
          int main(void) { return 0; }
          >
          are similar in that they both declare and define a function called
          "main". They differ in that, for example, one makes the call
          "main(42)", appearing in another function in the same translation unit
          following the above definition, invoke undefined behavior, while the
          other makes it a constraint violation.
          >
          The standard doesn't say that the definition of main must be very
          similar to "int main(void) { /* ... */ }", differing only in ways that
          have no effect on the particular program being considered. It says
          that it must be *equivalent* (or it must follow one of the other two
          options).
          >
          In practice, most or all C compilers do support "int main()" with the
          obvious semantics. If my interpretation is correct (and no, I'm not
          100% certain of that), then "int main()", in an implementation that
          doesn't document it, invokes undefined behavior; [...]
          A good argument, and well presented.

          The argument hinges on the function definition

          int main(){ return 0; }

          not supplying a prototype for main(). Is that in fact the case? I
          would like to give an argument that this definition does in fact
          supply a prototype for main(). First the definition for prototype,
          given in the last sentence of 6.2.1p2:

          For each different entity that an identifier designates, the
          identifier is visible (i.e., can be used) only within a region of
          program text called its scope. Different entities designated by the
          same identifier either have different scopes, or are in different
          name spaces. 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.)

          Now a relevant paragraph from the section on function declarators,
          namely 6.7.3p14:

          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)

          Note the second sentence, and contrast it with the third sentence.
          Also, this paragraph being in the section on function /declarators/
          is germane to the argument. The explicit specification that the
          declared function has no parameters means this declaration does
          indeed declare the types of its parameters.

          The footnote reference (126) says:

          126) See ``future language directions'' (6.11.6).

          This section and the one after it merit examination:

          6.11.6 Function declarators

          1 The use of function declarators with empty parentheses (not
          prototype-format parameter type declarators) is an obsolescent
          feature.

          6.11.7 Function definitions

          1 The use of function definitions with separate parameter identifier
          and declaration lists (not prototype-format parameter type and
          identifier declarators) is an obsolescent feature.

          Again, contrast the wording in the two paragraphs. The wording
          identifying "not prototype-format" style is different in the
          case of function definitions, which supports the proposition.

          The opposite side of this argument is (a) 6.11.6 would seem to apply
          to function declarators /in definitions/ in addition to function
          declarations /not/ in definitions, and (b) wording in other places in
          the standard suggests "prototype" is synonymous with there being a
          parameter-type-list.

          Looking at both sides, the explicit statement in 6.7.3p14, especially
          in contrast to the corresponding statement for declarations not part
          of a definition, makes the argument "for" seem a little stronger than
          the argument "against". Is there a crushing counter-argument that
          I'm missing?

          [My apologies if part of this message gets posted twice... editor error]

          Comment

          • Tim Rentsch

            #20
            Re: (part 21) Han from China answers your C questions

            Harald van =?UTF-8?b?RMSzaw==?= <truedfx@gmail. comwrites:
            Perhaps also interesting is that
            >
            int main(int argc, char *argv[]) {
            /* ... */
            }
            >
            is not equivalent to
            >
            int main(int argc, char *argv[]);
            int main(argc, argv)
            int argc;
            char *argv[];
            {
            /* ... */
            }
            >
            because the latter allows main to be called as
            >
            int (*mainptr)() = &main;
            (*mainptr)(1u, (char **) 0);
            >
            while the former doesn't, but this doesn't apply to () versus (void).
            Actually I think they are the same, because the rules for composite
            types cause the K&R-style definition of main to acquire a prototype.
            6.5.2.2p6:

            If the expression that denotes the called function has a type that
            does not include a prototype, the integer promotions are performed on
            each argument, and arguments that have type float are promoted to
            double. These are called the default argument promotions. If the
            number of arguments does not equal the number of parameters, the
            behavior is undefined. If the function is defined with a type that
            includes a prototype, [...]

            Is main defined with a type that includes a prototype? 6.2.7p4:

            For an identifier with internal or external linkage declared in a
            scope in which a prior declaration of that identifier is visible, if
            the prior declaration specifies internal or external linkage, the type
            of the identifier at the later declaration becomes the composite type.

            What is the composite type? 6.2.7p3, subitem 2:

            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 the K&R-style main() with preceeding prototype should behave
            just as though it were defined with a prototype.

            Comment

            • Andrey Tarasevich

              #21
              Re: (part 21) Han from China answers your C questions

              Tim Rentsch wrote:
              ...
              Looking at both sides, the explicit statement in 6.7.3p14, especially
              in contrast to the corresponding statement for declarations not part
              of a definition, makes the argument "for" seem a little stronger than
              the argument "against". Is there a crushing counter-argument that
              I'm missing?
              ...
              Please, take a look at DR#317



              It doesn't give a "crushing counter-argument" in terms of a rationale,
              but does make the committee's intent clear in rather unambiguous manner.

              --
              Best regards,
              Andrey Tarasevich

              Comment

              • Harald van =?UTF-8?b?RMSzaw==?=

                #22
                Re: (part 21) Han from China answers your C questions

                On Tue, 18 Nov 2008 10:33:34 -0800, Tim Rentsch wrote:
                Harald van =?UTF-8?b?RMSzaw==?= <truedfx@gmail. comwrites:
                >int main(int argc, char *argv[]);
                >int main(argc, argv)
                > int argc;
                > char *argv[];
                >{
                > /* ... */
                >}
                >
                Actually I think they are the same, because the rules for composite
                types cause the K&R-style definition of main to acquire a prototype.
                [...]
                Is main defined with a type that includes a prototype? 6.2.7p4:
                >
                For an identifier with internal or external linkage declared in a
                scope in which a prior declaration of that identifier is visible, if
                the prior declaration specifies internal or external linkage, the
                type of the identifier at the later declaration becomes the
                composite type.
                Interesting point. A function definition is an external-declaration, not a
                declaration, according to the grammar, so I'm not sure if this applies,
                but it's very well possible that you're right.

                Comment

                • Keith Thompson

                  #23
                  Re: (part 21) Han from China answers your C questions

                  Tim Rentsch <txr@alumnus.ca ltech.eduwrites :
                  Keith Thompson <kst-u@mib.orgwrites :
                  [BIG SNIP]
                  >>
                  >The standard doesn't say that the definition of main must be very
                  >similar to "int main(void) { /* ... */ }", differing only in ways that
                  >have no effect on the particular program being considered. It says
                  >that it must be *equivalent* (or it must follow one of the other two
                  >options).
                  >>
                  >In practice, most or all C compilers do support "int main()" with the
                  >obvious semantics. If my interpretation is correct (and no, I'm not
                  >100% certain of that), then "int main()", in an implementation that
                  >doesn't document it, invokes undefined behavior; [...]
                  >
                  A good argument, and well presented.
                  Thank you.
                  The argument hinges on the function definition
                  >
                  int main(){ return 0; }
                  >
                  not supplying a prototype for main(). Is that in fact the case? I
                  would like to give an argument that this definition does in fact
                  supply a prototype for main(). First the definition for prototype,
                  given in the last sentence of 6.2.1p2:
                  >
                  For each different entity that an identifier designates, the
                  identifier is visible (i.e., can be used) only within a region of
                  program text called its scope. Different entities designated by the
                  same identifier either have different scopes, or are in different
                  name spaces. 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.)
                  >
                  Now a relevant paragraph from the section on function declarators,
                  namely 6.7.3p14:
                  Typo: that's 6.7.5.3p14.
                  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)
                  >
                  Note the second sentence, and contrast it with the third sentence.
                  Also, this paragraph being in the section on function /declarators/
                  is germane to the argument. The explicit specification that the
                  declared function has no parameters means this declaration does
                  indeed declare the types of its parameters.
                  Fascinating. I've always assumed that an empty list was just the
                  zero-parameter case of a K&R-style non-prototype declaration, but the
                  above implies that it acts like a "(void)" prototype.

                  I still suspect that that wasn't the intent. I think what was meant
                  is that the "()" specifies *for the function definition* that the
                  function has no parameters. And just as a matter of consistency, I'd
                  prefer to have a general (implied) rule that any function declaration
                  that was legal in K&R1 is not a prototype.

                  But of course we have to go by what the standard actually says.

                  If your interpretation is correct, then the call to main in this:

                  int main() { return 0; }
                  void foo(void) { main(42); }

                  violates a constraint; I haven't seen a compiler that will diagnose
                  it.
                  The footnote reference (126) says:
                  >
                  126) See ``future language directions'' (6.11.6).
                  >
                  This section and the one after it merit examination:
                  >
                  6.11.6 Function declarators
                  >
                  1 The use of function declarators with empty parentheses (not
                  prototype-format parameter type declarators) is an obsolescent
                  feature.
                  >
                  6.11.7 Function definitions
                  >
                  1 The use of function definitions with separate parameter identifier
                  and declaration lists (not prototype-format parameter type and
                  identifier declarators) is an obsolescent feature.
                  >
                  Again, contrast the wording in the two paragraphs. The wording
                  identifying "not prototype-format" style is different in the
                  case of function definitions, which supports the proposition.
                  My guess is that the authors just didn't think about the
                  zero-parameter case, and therefore failed to cover it adequately.
                  The opposite side of this argument is (a) 6.11.6 would seem to apply
                  to function declarators /in definitions/ in addition to function
                  declarations /not/ in definitions, and (b) wording in other places in
                  the standard suggests "prototype" is synonymous with there being a
                  parameter-type-list.
                  >
                  Looking at both sides, the explicit statement in 6.7.3p14, especially
                  Again, that's 6.7.5.3p14.
                  in contrast to the corresponding statement for declarations not part
                  of a definition, makes the argument "for" seem a little stronger than
                  the argument "against". Is there a crushing counter-argument that
                  I'm missing?
                  >
                  [My apologies if part of this message gets posted twice... editor error]
                  --
                  Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
                  Nokia
                  "We must do something. This is something. Therefore, we must do this."
                  -- Antony Jay and Jonathan Lynn, "Yes Minister"

                  Comment

                  • Andrey Tarasevich

                    #24
                    Re: (part 21) Han from China answers your C questions

                    Keith Thompson wrote:
                    >This section and the one after it merit examination:
                    >>
                    > 6.11.6 Function declarators
                    >>
                    > 1 The use of function declarators with empty parentheses (not
                    > prototype-format parameter type declarators) is an obsolescent
                    > feature.
                    >>
                    > 6.11.7 Function definitions
                    >>
                    > 1 The use of function definitions with separate parameter identifier
                    > and declaration lists (not prototype-format parameter type and
                    > identifier declarators) is an obsolescent feature.
                    >>
                    >Again, contrast the wording in the two paragraphs. The wording
                    >identifying "not prototype-format" style is different in the
                    >case of function definitions, which supports the proposition.
                    >
                    My guess is that the authors just didn't think about the
                    zero-parameter case, and therefore failed to cover it adequately.
                    As it is stated in the committee response to DR#317, it is actually
                    covered adequately, although the full logical chain begins at a rather
                    unexpected point: the key moment here is that according to the _grammar_
                    the empty '()' stands for an empty _identifier_ list, not for an empty
                    typed parameter list. And according to this, an empty '()' in the
                    definition does not include a parameter list and therefore does not
                    satisfy the definition of a prototype (which happens to require a
                    parameter list in the function declaration).

                    --
                    Best regards,
                    Andrey Tarasevich

                    Comment

                    • Tim Rentsch

                      #25
                      Re: (part 21) Han from China answers your C questions

                      Harald van =?UTF-8?b?RMSzaw==?= <truedfx@gmail. comwrites:
                      On Tue, 18 Nov 2008 10:33:34 -0800, Tim Rentsch wrote:
                      Harald van =?UTF-8?b?RMSzaw==?= <truedfx@gmail. comwrites:
                      int main(int argc, char *argv[]);
                      int main(argc, argv)
                      int argc;
                      char *argv[];
                      {
                      /* ... */
                      }
                      Actually I think they are the same, because the rules for composite
                      types cause the K&R-style definition of main to acquire a prototype.
                      [...]
                      Is main defined with a type that includes a prototype? 6.2.7p4:

                      For an identifier with internal or external linkage declared in a
                      scope in which a prior declaration of that identifier is visible, if
                      the prior declaration specifies internal or external linkage, the
                      type of the identifier at the later declaration becomes the
                      composite type.
                      >
                      Interesting point. A function definition is an external-declaration, not a
                      declaration, according to the grammar, so I'm not sure if this applies,
                      but it's very well possible that you're right.
                      There is 6.7 p 5:

                      A declaration specifies the interpretation and attributes of a
                      set of identifiers. A definition of an identifier is a
                      declaration for that identifier that:

                      - for an object, causes storage to be reserved for that object;
                      - for a function, includes the function body;101)
                      - for an enumeration constant or typedef name, is the (only)
                      declaration of the identifier.

                      with 101)

                      101) Function definitions have a different syntax, described in 6.9.1.

                      Seems pretty black letter.

                      Comment

                      • Tim Rentsch

                        #26
                        Re: (part 21) Han from China answers your C questions

                        Andrey Tarasevich <andreytarasevi ch@hotmail.comw rites:
                        Tim Rentsch wrote:
                        ...
                        Looking at both sides, the explicit statement in 6.7.3p14, especially
                        in contrast to the corresponding statement for declarations not part
                        of a definition, makes the argument "for" seem a little stronger than
                        the argument "against". Is there a crushing counter-argument that
                        I'm missing?
                        ...
                        >
                        Please, take a look at DR#317
                        >

                        >
                        It doesn't give a "crushing counter-argument" in terms of a rationale,
                        but does make the committee's intent clear in rather unambiguous manner.
                        Well! This DR may not be "crushing", but it is pretty damning to my
                        argument. :)

                        I accept that the committee's intent (expressed clearly enough in the
                        DR) is that an empty argument list in a function definition does not
                        constitute a prototype. However, their reasoning is bogus. There is
                        nothing in the standard that ties the term "prototype" to the
                        syntactic nonterminal "parameter-type-list". A function definition
                        with an empty argument list satisfies the only statement in the text
                        that might reasonably be called a definition of "prototype" ; in
                        combination with the previous statement, that makes the argument
                        that it is a prototype a lot more convincing than the argument
                        that it isn't a prototype.

                        May I say, Harrumph!

                        (And also say thank you Andrey for pointing out the DR.)

                        Comment

                        • Tim Rentsch

                          #27
                          Re: (part 21) Han from China answers your C questions

                          Keith Thompson <kst-u@mib.orgwrites :
                          Tim Rentsch <txr@alumnus.ca ltech.eduwrites :
                          Keith Thompson <kst-u@mib.orgwrites :
                          [BIG SNIP]
                          >
                          The standard doesn't say that the definition of main must be very
                          similar to "int main(void) { /* ... */ }", differing only in ways that
                          have no effect on the particular program being considered. It says
                          that it must be *equivalent* (or it must follow one of the other two
                          options).
                          >
                          In practice, most or all C compilers do support "int main()" with the
                          obvious semantics. If my interpretation is correct (and no, I'm not
                          100% certain of that), then "int main()", in an implementation that
                          doesn't document it, invokes undefined behavior; [...]
                          A good argument, and well presented.
                          >
                          Thank you.
                          >
                          The argument hinges on the function definition

                          int main(){ return 0; }

                          not supplying a prototype for main(). Is that in fact the case? I
                          would like to give an argument that this definition does in fact
                          supply a prototype for main(). First the definition for prototype,
                          given in the last sentence of 6.2.1p2:

                          For each different entity that an identifier designates, the
                          identifier is visible (i.e., can be used) only within a region of
                          program text called its scope. Different entities designated by the
                          same identifier either have different scopes, or are in different
                          name spaces. 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.)

                          Now a relevant paragraph from the section on function declarators,
                          namely 6.7.3p14:
                          >
                          Typo: that's 6.7.5.3p14.
                          Quite right, thank you for the correction.
                          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)

                          Note the second sentence, and contrast it with the third sentence.
                          Also, this paragraph being in the section on function /declarators/
                          is germane to the argument. The explicit specification that the
                          declared function has no parameters means this declaration does
                          indeed declare the types of its parameters.
                          >
                          Fascinating. I've always assumed that an empty list was just the
                          zero-parameter case of a K&R-style non-prototype declaration, but the
                          above implies that it acts like a "(void)" prototype.
                          Syntactically, it does in fact match the K&R-style syntax rule,
                          and not the parameter-type-list syntax rule. My argument is
                          that, whichever syntax rule is involved, an empty parameter list
                          in a function definition satisfies the definition of "prototype"
                          and therefore ought to be considered as such.
                          I still suspect that that wasn't the intent. I think what was meant
                          is that the "()" specifies *for the function definition* that the
                          function has no parameters. And just as a matter of consistency, I'd
                          prefer to have a general (implied) rule that any function declaration
                          that was legal in K&R1 is not a prototype.
                          Yes, the DR makes clear that it wasn't the intent. Your point about
                          the function having no parameters brings out a subtle distinction. If
                          we consider (giving the right section number this time!) 6.7.5.3p5:

                          If, in the declaration ..T D1.., D1 has the form

                          D( parameter-type-list )
                          or

                          D( identifier-listopt )

                          and the type specified for ident in the declaration ``T D'' is
                          ``derived-declarator-type-list T'', then the type specified for
                          ident is ``derived-declarator-type-list function returning T''.

                          In p14 it's the /function/ that has no parameters, whereas in p5
                          it's the /type specified for ident/ that has a particular return
                          type. This distinction, which I hadn't noticed before, weakens
                          my argument.

                          But of course we have to go by what the standard actually says.
                          >
                          If your interpretation is correct, then the call to main in this:
                          >
                          int main() { return 0; }
                          void foo(void) { main(42); }
                          >
                          violates a constraint; I haven't seen a compiler that will diagnose
                          it.
                          [remainder snipped]
                          Yes, that's a valid conclusion, and it isn't surprising that
                          compilers don't report it. This gives a slim ray of hope --
                          if compilers simply started reporting this as an error
                          (which certainly seems reasonable, since it is guaranteed
                          UB if ever executed), then the standard committee might be
                          convinced to let such function definitions serve as prototypes.

                          Comment

                          • Tim Rentsch

                            #28
                            Re: (part 21) Han from China answers your C questions

                            Andrey Tarasevich <andreytarasevi ch@hotmail.comw rites:
                            Keith Thompson wrote:
                            This section and the one after it merit examination:
                            >
                            6.11.6 Function declarators
                            >
                            1 The use of function declarators with empty parentheses (not
                            prototype-format parameter type declarators) is an obsolescent
                            feature.
                            >
                            6.11.7 Function definitions
                            >
                            1 The use of function definitions with separate parameter identifier
                            and declaration lists (not prototype-format parameter type and
                            identifier declarators) is an obsolescent feature.
                            >
                            Again, contrast the wording in the two paragraphs. The wording
                            identifying "not prototype-format" style is different in the
                            case of function definitions, which supports the proposition.
                            My guess is that the authors just didn't think about the
                            zero-parameter case, and therefore failed to cover it adequately.
                            >
                            As it is stated in the committee response to DR#317, it is actually
                            covered adequately, although the full logical chain begins at a rather
                            unexpected point: the key moment here is that according to the _grammar_
                            the empty '()' stands for an empty _identifier_ list, not for an empty
                            typed parameter list. And according to this, an empty '()' in the
                            definition does not include a parameter list and therefore does not
                            satisfy the definition of a prototype (which happens to require a
                            parameter list in the function declaration).
                            There is no statement in the standard that says a prototype requires a
                            parameter list. The only statement that comes close to being a
                            definition is given inside parentheses in 6.2.1p2:

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

                            A function definition that has no parameters satisfies this
                            definition - it has no parameters, and it declares the type
                            of every one of them.

                            Also, the term "prototype" is never mentioned in conjunction with
                            either of the nonterminal symbols "parameter-type-list" or
                            "identifier-list".

                            Again I say, Harrumph!

                            Comment

                            • Keith Thompson

                              #29
                              Re: (part 21) Han from China answers your C questions

                              Tim Rentsch <txr@alumnus.ca ltech.eduwrites :
                              Andrey Tarasevich <andreytarasevi ch@hotmail.comw rites:
                              [...]
                              >As it is stated in the committee response to DR#317, it is actually
                              >covered adequately, although the full logical chain begins at a rather
                              >unexpected point: the key moment here is that according to the _grammar_
                              >the empty '()' stands for an empty _identifier_ list, not for an empty
                              >typed parameter list. And according to this, an empty '()' in the
                              >definition does not include a parameter list and therefore does not
                              >satisfy the definition of a prototype (which happens to require a
                              >parameter list in the function declaration).
                              >
                              There is no statement in the standard that says a prototype requires a
                              parameter list. The only statement that comes close to being a
                              definition is given inside parentheses in 6.2.1p2:
                              >
                              (A function prototype is a declaration of a function that
                              declares the types of its parameters.)
                              >
                              A function definition that has no parameters satisfies this
                              definition - it has no parameters, and it declares the type
                              of every one of them.
                              >
                              Also, the term "prototype" is never mentioned in conjunction with
                              either of the nonterminal symbols "parameter-type-list" or
                              "identifier-list".
                              >
                              Again I say, Harrumph!
                              The Committee is making a ruling based on the intent of the authors of
                              the standard, even though it may contradict the actual wording of the
                              standard.

                              They're The Committee. They get to do things like that.

                              I'm reminded of a ruling by the committee for one of the Algol
                              standards (60 or 68, I don't remember which), that said something
                              like

                              In section such-and-such, the word "is" shall be interpreted to
                              mean "is not".

                              In any case, I think that treating a declaration with empty
                              parentheses as a non-prototype just make more sense (again, even if
                              the current wording doesn't support that treatment).

                              I hope that wording in the next version of the standard is revised to
                              be consistent with the intent.

                              Nevertheless, I will gladly join you in your response:

                              Harrumph!

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

                              Comment

                              • lawrence.jones@siemens.com

                                #30
                                Re: (part 21) Han from China answers your C questions

                                Tim Rentsch <txr@alumnus.ca ltech.eduwrote:
                                >
                                There is
                                nothing in the standard that ties the term "prototype" to the
                                syntactic nonterminal "parameter-type-list".
                                6.2.7p3:

                                -- If only one type is a function type with a parameter type
                                list (a function prototype) ...

                                6.9.1p7:

                                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.

                                6.11.7:

                                The use of function declarators with empty parentheses (not
                                prototype-format parameter type declarators) is an obsolescent
                                feature.
                                --
                                Larry Jones

                                Buddy, if you think I'm even going to BE here, you're crazy! -- Calvin

                                Comment

                                Working...