confused with function declarations

Discussion in 'C Programming' started by Xiaoshen Li, Dec 21, 2005.

  1. Xiaoshen Li

    Xiaoshen Li Guest

    Dear All,

    I am confused with prototypes in C. I saw the following code in a C book:


    void init_array_1(int data[])
    {
    /* some code here */
    }


    void init_array_2(int *data_ptr)
    {
    /* some code here*/
    }

    int main()
    {
    int array[MAX];

    void init_array_1();
    void init_array_2();

    /*some code ommited*/

    return (0);
    }

    I don't understand why we need the two lines of function declarations
    inside main:
    void init_array_1();
    void init_array_2();

    Normally I would put them before main() and put those function
    definitions after main. If the two functions block have been put before
    main, I would thought no function declarations are needed any more.

    Thank you very much.
    Xiaoshen Li, Dec 21, 2005
    #1
    1. Advertising

  2. Xiaoshen Li

    pete Guest

    Xiaoshen Li wrote:
    >
    > Dear All,
    >
    > I am confused with prototypes in C. I saw the following code in a C book:
    >
    > void init_array_1(int data[])
    > {
    > /* some code here */
    > }
    >
    > void init_array_2(int *data_ptr)
    > {
    > /* some code here*/
    > }
    >
    > int main()
    > {
    > int array[MAX];
    >
    > void init_array_1();
    > void init_array_2();
    >
    > /*some code ommited*/
    >
    > return (0);
    > }
    >
    > I don't understand why we need the two lines of function declarations
    > inside main:
    > void init_array_1();
    > void init_array_2();


    We don't.

    > Normally I would put them before main() and put those function
    > definitions after main.


    So would I.

    > If the two functions block have been put before
    > main, I would thought no function declarations are needed any more.


    You would have thought correctly.

    --
    pete
    pete, Dec 21, 2005
    #2
    1. Advertising

  3. Xiaoshen Li

    pemo Guest

    "Xiaoshen Li" <> wrote in message
    news:docko3$cee$...
    > Dear All,
    >
    > I am confused with prototypes in C. I saw the following code in a C book:
    >
    >
    > void init_array_1(int data[])
    > {
    > /* some code here */
    > }
    >
    >
    > void init_array_2(int *data_ptr)
    > {
    > /* some code here*/
    > }
    >
    > int main()
    > {
    > int array[MAX];
    >
    > void init_array_1();
    > void init_array_2();
    >
    > /*some code ommited*/
    >
    > return (0);
    > }
    >
    > I don't understand why we need the two lines of function declarations
    > inside main:
    > void init_array_1();
    > void init_array_2();
    >
    > Normally I would put them before main() and put those function definitions
    > after main. If the two functions block have been put before main, I would
    > thought no function declarations are needed any more.
    >


    It'd be interesting to know which book you were using, and what the subject
    under discussion was when this code appeared.

    What you've posted shows two function *definitions* - ahead of main - and
    two differing predecs for those same functions inside of main. However, the
    latter predecs change the shape of things - as the *say* that the compiler's
    no idea what you're going to pass to these two functions at runtime. So,
    they're somewhat in conflict with the external definitions [and the implicit
    declarations that these make - when they appeared].

    As they're seen later by the compiler, the latter predecs essentially
    overrule the earlier definitions seen?

    For example ...

    :::This says that init_array_1 expects an int[] to be passed to it.

    void init_array_1(int data[])
    {
    }


    int main(void)
    {

    ::: this says 'forget what you've heard about this function - you don't know
    what it'll be passed!!!'
    :::
    void init_array_1();

    char x;

    ::: pass a char to init_array_1 - it [the compiler] had better not
    complain - as we told it to forget stuff!

    init_array_1(x);
    }

    Lastly, it is more usual to see predecs ahead of main ... possibly because
    include files mainly provude these, and are *normally* included ahead of any
    code [although there's no real reason to do this - just as long as things
    are seen before they're used].
    pemo, Dec 21, 2005
    #3
  4. Xiaoshen Li

    pemo Guest

    "pete" <> wrote in message
    news:...
    > Xiaoshen Li wrote:
    >>
    >> Dear All,
    >>
    >> I am confused with prototypes in C. I saw the following code in a C book:
    >>
    >> void init_array_1(int data[])
    >> {
    >> /* some code here */
    >> }
    >>
    >> void init_array_2(int *data_ptr)
    >> {
    >> /* some code here*/
    >> }
    >>
    >> int main()
    >> {
    >> int array[MAX];
    >>
    >> void init_array_1();
    >> void init_array_2();
    >>
    >> /*some code ommited*/
    >>
    >> return (0);
    >> }
    >>
    >> I don't understand why we need the two lines of function declarations
    >> inside main:
    >> void init_array_1();
    >> void init_array_2();

    >
    > We don't.
    >
    >> Normally I would put them before main() and put those function
    >> definitions after main.

    >
    > So would I.
    >
    >> If the two functions block have been put before
    >> main, I would thought no function declarations are needed any more.

    >
    > You would have thought correctly.


    I would say 'have you nothing better to do!' [at 11.00pm] - but I hate
    reality-reflection - so, I won't say it!

    Damn it, oops, Ctrl+Z

    damn it again!
    pemo, Dec 21, 2005
    #4
  5. Xiaoshen Li

    pete Guest

    pemo wrote:
    >
    > "pete" <> wrote in message
    > news:...
    > > Xiaoshen Li wrote:
    > >>
    > >> Dear All,
    > >>
    > >> I am confused with prototypes in C.
    > >> I saw the following code in a C book:
    > >>
    > >> void init_array_1(int data[])
    > >> {
    > >> /* some code here */
    > >> }
    > >>
    > >> void init_array_2(int *data_ptr)
    > >> {
    > >> /* some code here*/
    > >> }
    > >>
    > >> int main()
    > >> {
    > >> int array[MAX];
    > >>
    > >> void init_array_1();
    > >> void init_array_2();
    > >>
    > >> /*some code ommited*/
    > >>
    > >> return (0);
    > >> }
    > >>
    > >> I don't understand why we need
    > >> the two lines of function declarations
    > >> inside main:
    > >> void init_array_1();
    > >> void init_array_2();

    > >
    > > We don't.
    > >
    > >> Normally I would put them before main() and put those function
    > >> definitions after main.

    > >
    > > So would I.


    .... except that I would have written them as protoypes,
    instead of merely as declarations.

    #define MAX 1

    void init_array_1(int *data);
    void init_array_2(int *data_ptr);

    int main(void)
    {
    int array[MAX];

    return 0;
    }

    void init_array_1(int *data)
    {
    /* some code here */
    }

    void init_array_2(int *data_ptr)
    {
    /* some code here*/
    }

    --
    pete
    pete, Dec 22, 2005
    #5
  6. Xiaoshen Li

    Xiaoshen Li Guest

    Xiaoshen Li, Dec 22, 2005
    #6
  7. Xiaoshen Li

    Jordan Abel Guest

    On 2005-12-22, Xiaoshen Li <> wrote:
    > The code is from the book "Practical C Programming" 1997, Chapter 13,
    > which is available in the link:
    >
    > http://www.oreilly.com/catalog/pcp3/chapter/ch13.html#48674
    >
    > Example 13-6.
    >
    > I really like this book. Hard to believe that the author could be wrong.


    What exactly are you confused about?
    Jordan Abel, Dec 22, 2005
    #7
  8. Xiaoshen Li

    Flash Gordon Guest

    Xiaoshen Li wrote:
    > The code is from the book "Practical C Programming" 1997, Chapter 13,
    > which is available in the link:
    >
    > http://www.oreilly.com/catalog/pcp3/chapter/ch13.html#48674
    >
    > Example 13-6.
    >
    > I really like this book. Hard to believe that the author could be wrong.


    I don't. I know of enough bad technical books to find it very easy to
    believe an author is wrong. In this case though, I believe it is more a
    case fo using a very bad style than something that is completely wrong.

    I also note that this author is using the term "procedure" when in C it
    is usual to refer even to void functions as functions.

    It also says, "Finally, there is a special pointer called NULL. It
    points to nothing. (The actual numeric value is 0.) The standard include
    file, locale.h, defines the constant NULL. (This file is usually not
    directly included, but is usually brought in by the include files
    stdio.h or stdlib.h.)" which is wrong or misleading on several points.

    It is incorrect in saying that NULL is the name of a pointer, NULL is a
    macro that expands to a null pointer.
    It is correct that locale.h defines the NULL macro.
    It is at least misleading saying that that stdio.h and stdlib.h include
    locale.h, since on many systems it may not and even if it does you still
    won't get the other things that locale.h defines.

    It shows an example that modifies a string literal with a comment that
    it is legal. This is wrong, the compiler is not required to complain,
    but it is also not required to produce working code since attempting to
    modify a string literal is undefined behaviour.

    It shows using the %p format specifier without casting the pointer to
    void*, %p is only valid for pointers to void.

    There are probably other errors that I have not spotted on a quick look.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Dec 22, 2005
    #8
  9. Xiaoshen Li

    pete Guest

    Xiaoshen Li wrote:
    >
    > The code is from the book "Practical C Programming" 1997, Chapter 13,
    > which is available in the link:
    >
    > http://www.oreilly.com/catalog/pcp3/chapter/ch13.html#48674
    >
    > Example 13-6.
    >
    > I really like this book.
    > Hard to believe that the author could be wrong.


    Many C tutorials are written by people who are wrong.
    Placing function declarations inside of function definitions,
    is awkward style. (also bad because it's awkward)

    The use of nonprototype function declarations,
    is bad style.

    The
    int main()
    style definition, is also obsolescent.
    int main(void)
    is better.

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/
    N869
    6.11.4 Function declarators
    [#1] The use of function declarators with empty parentheses
    (not prototype-format parameter type declarators) is an
    obsolescent feature.

    --
    pete
    pete, Dec 22, 2005
    #9
  10. Flash Gordon <> writes:
    > Xiaoshen Li wrote:
    >> The code is from the book "Practical C Programming" 1997, Chapter
    >> 13, which is available in the link:
    >> http://www.oreilly.com/catalog/pcp3/chapter/ch13.html#48674
    >> Example 13-6.
    >> I really like this book. Hard to believe that the author could be
    >> wrong.

    >
    > I don't. I know of enough bad technical books to find it very easy to
    > believe an author is wrong. In this case though, I believe it is more
    > a case fo using a very bad style than something that is completely
    > wrong.
    >
    > I also note that this author is using the term "procedure" when in C
    > it is usual to refer even to void functions as functions.
    >
    > It also says, "Finally, there is a special pointer called NULL. It
    > points to nothing. (The actual numeric value is 0.) The standard
    > include file, locale.h, defines the constant NULL. (This file is
    > usually not directly included, but is usually brought in by the
    > include files stdio.h or stdlib.h.)" which is wrong or misleading on
    > several points.
    >
    > It is incorrect in saying that NULL is the name of a pointer, NULL is
    > a macro that expands to a null pointer.


    No, NULL is a macro that expands to a null pointer constant.
    [snip]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Dec 22, 2005
    #10
  11. Xiaoshen Li

    Flash Gordon Guest

    Keith Thompson wrote:
    > Flash Gordon <> writes:
    >> Xiaoshen Li wrote:


    <snip>

    >> It is incorrect in saying that NULL is the name of a pointer, NULL is
    >> a macro that expands to a null pointer.

    >
    > No, NULL is a macro that expands to a null pointer constant.
    > [snip]


    Damn, I missed one word. That'll teach me to reply hurriedly when I
    should be working :)

    Actually, it probably won't. ;-)
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Dec 22, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Theese

    Local function declarations

    Dave Theese, Sep 5, 2003, in forum: C++
    Replies:
    1
    Views:
    453
    Jack Klein
    Sep 5, 2003
  2. TechCrazy

    const in function declarations

    TechCrazy, Apr 21, 2005, in forum: C++
    Replies:
    6
    Views:
    389
    Grant Schoep
    Apr 24, 2005
  3. Marcus Lessard

    Mangled function type declarations?

    Marcus Lessard, Oct 17, 2003, in forum: C Programming
    Replies:
    1
    Views:
    348
    Eric Sosman
    Oct 17, 2003
  4. Billy Patton

    Function declarations/defaults

    Billy Patton, Nov 14, 2003, in forum: C Programming
    Replies:
    17
    Views:
    540
    Chris Torek
    Nov 19, 2003
  5. Douglas
    Replies:
    2
    Views:
    330
    Herbert Rosenau
    Jul 5, 2004
Loading...

Share This Page