prototypes

Discussion in 'C Programming' started by DevarajA, Jul 19, 2005.

  1. DevarajA

    DevarajA Guest

    If a function is visible everywhere, even out the file where it is
    declared and defined, why should i write prototypes?
    --
    Devaraja (Xdevaraja87^gmail^c0mX)
    Linux Registerd User #338167
    http://counter.li.org
    DevarajA, Jul 19, 2005
    #1
    1. Advertising

  2. DevarajA

    DevarajA Guest

    DevarajA ha scritto:
    > If a function is visible everywhere, even out the file where it is
    > declared and defined, why should i write prototypes?


    I've just read that they're used for type checking when calling external
    functions. Is that true?

    --
    Devaraja (Xdevaraja87^gmail^c0mX)
    Linux Registerd User #338167
    http://counter.li.org
    DevarajA, Jul 19, 2005
    #2
    1. Advertising

  3. DevarajA

    osmium Guest

    "DevarajA" <> wrote in message
    news:Om7De.179767$...

    > DevarajA ha scritto:
    >> If a function is visible everywhere, even out the file where it is
    >> declared and defined, why should i write prototypes?

    >
    > I've just read that they're used for type checking when calling external
    > functions. Is that true?


    The thing described by the OP (who,oddly enough, has the same nym as you) is
    not an external function. He said it was *visible*. C does compiling in a
    forward direction and it must know the argument types when it compiles. So
    if you do the physical definition prior to the first usage you don't need a
    prototype. This is sometimes called "Pascal style". The prototypes for
    external functions are usually in a visible header file.
    osmium, Jul 19, 2005
    #3
  4. DevarajA

    DevarajA Guest

    osmium ha scritto:
    > "DevarajA" <> wrote in message
    > news:Om7De.179767$...
    >
    >
    >>DevarajA ha scritto:
    >>
    >>>If a function is visible everywhere, even out the file where it is
    >>>declared and defined, why should i write prototypes?

    >>
    >>I've just read that they're used for type checking when calling external
    >>functions. Is that true?

    >
    >
    > The thing described by the OP (who,oddly enough, has the same nym as you) is
    > not an external function. He said it was *visible*. C does compiling in a
    > forward direction and it must know the argument types when it compiles. So
    > if you do the physical definition prior to the first usage you don't need a
    > prototype. This is sometimes called "Pascal style". The prototypes for
    > external functions are usually in a visible header file.
    >
    >


    so why this works and only gives "implicit declaration" warnings?

    int main()
    {
    a(8,9);
    b(9,9.5);
    c(9.5,10);
    return 0;
    }
    int a(int x, int y){return 0;}
    int b(int x, double y){return 0;}
    int c(double x, int y){return 0;}


    --
    Devaraja (Xdevaraja87^gmail^c0mX)
    Linux Registerd User #338167
    http://counter.li.org
    DevarajA, Jul 19, 2005
    #4
  5. DevarajA

    osmium Guest

    "DevarajA" writes:

    > so why this works and only gives "implicit declaration" warnings?
    >
    > int main()
    > {
    > a(8,9);
    > b(9,9.5);
    > c(9.5,10);
    > return 0;
    > }
    > int a(int x, int y){return 0;}
    > int b(int x, double y){return 0;}
    > int c(double x, int y){return 0;}


    There was a time when something called K&R C was a more or less de facto
    standard. Before there was a real standard. It assumed that everything was
    int. Your compiler is in a mode such that it accepts the old dialect.
    osmium, Jul 19, 2005
    #5
  6. DevarajA

    DevarajA Guest

    osmium ha scritto:
    > "DevarajA" writes:
    >
    >
    >>so why this works and only gives "implicit declaration" warnings?
    >>
    >>int main()
    >>{
    >> a(8,9);
    >> b(9,9.5);
    >> c(9.5,10);
    >> return 0;
    >>}
    >>int a(int x, int y){return 0;}
    >>int b(int x, double y){return 0;}
    >>int c(double x, int y){return 0;}

    >
    >
    > There was a time when something called K&R C was a more or less de facto
    > standard. Before there was a real standard. It assumed that everything was
    > int. Your compiler is in a mode such that it accepts the old dialect.
    >
    >


    So for that old standard a call to a undeclared function f1 is an
    implicit declaration (as int f1(...))?

    --
    Devaraja (Xdevaraja87^gmail^c0mX)
    Linux Registerd User #338167
    http://counter.li.org
    DevarajA, Jul 19, 2005
    #6
  7. DevarajA

    John Bode Guest

    DevarajA wrote:
    > If a function is visible everywhere, even out the file where it is
    > declared and defined, why should i write prototypes?
    > --
    > Devaraja (Xdevaraja87^gmail^c0mX)
    > Linux Registerd User #338167
    > http://counter.li.org


    You need to have a prototype declaration in scope if the function is
    being called before it has been defined. If you have all your
    functions in the same file, and you define each function before it is
    used, you don't need a prototype declaration.

    Example:

    double foo(int x, float y)
    {
    ...
    }

    char *bar(void)
    {
    ...
    double g = foo(1, 2.0);
    }

    int main(void)
    {
    char *msg = bar();
    ...
    }

    Since the functions are defined (using prototype syntax) before they
    are called, the compiler is able to verify that the return types and
    the number and types of arguments match between the definition and
    call.

    Now, suppose the order were reversed:

    int main (void)
    {
    char *msg = bar();
    ...
    }

    char *bar(void)
    {
    double g = foo(1, 2.0);
    ...
    }

    double foo(int x, float y);
    {
    ...
    }


    When the compiler sees the call to bar(), it has no prior definition or
    declaration of bar in scope, so it assumes bar() returns int, and does
    no parameter checking. In this case, the compiler should issue a
    diagnostic since it thinks you're trying to assign an int value to a
    char *. Similarly, when the compiler first sees the call to foo(), it
    assumes that foo() returns int, does no checking on the parameters, and
    applies the default type promotions (IIRC, without a definition or
    declaration in scope, 2.0 will be passed as a double instead of a
    float). Again, you'll get a warning about trying to assign an int to a
    double.
    John Bode, Jul 19, 2005
    #7
  8. DevarajA

    Eric Sosman Guest

    osmium wrote:
    > "DevarajA" <> wrote in message
    > news:Om7De.179767$...
    >
    >
    >>DevarajA ha scritto:
    >>
    >>>If a function is visible everywhere, even out the file where it is
    >>>declared and defined, why should i write prototypes?

    >>
    >>I've just read that they're used for type checking when calling external
    >>functions. Is that true?

    >
    >
    > The thing described by the OP (who,oddly enough, has the same nym as you) is
    > not an external function. He said it was *visible*. C does compiling in a
    > forward direction and it must know the argument types when it compiles. So
    > if you do the physical definition prior to the first usage you don't need a
    > prototype. This is sometimes called "Pascal style". The prototypes for
    > external functions are usually in a visible header file.


    There's some evidence of confusion here, so to clear
    the air: A prototype is the parenthesis-enclosed list of
    types or type/argument pairs that appears in a function
    declaration. It is possible to declare a function with
    a prototype

    double func(double, int, const char*);

    or without a prototype

    double func();

    Equally, it is possible to define a function with a
    prototype

    double func(double x, int i, const char *s) {
    return x + i * strlen(s);
    }

    or without a prototype

    double func(x, i, s)
    double x;
    int i;
    const char *s;
    {
    return x + i * strlen(s);
    }

    DevarajA and osmium seem to be saying "prototype" when
    what they actually mean is "declaration." osmium's point
    is that a function definition is also a declaration (though
    the opposite is clearly not true), and is really not about
    prototypes at all.

    --
    Eric Sosman, Jul 19, 2005
    #8
  9. DevarajA

    Eric Sosman Guest

    John Bode wrote:
    >
    > DevarajA wrote:
    >
    >>If a function is visible everywhere, even out the file where it is
    >>declared and defined, why should i write prototypes?
    >>--
    >>Devaraja (Xdevaraja87^gmail^c0mX)
    >>Linux Registerd User #338167
    >>http://counter.li.org

    >
    >
    > You need to have a prototype declaration in scope if the function is
    > being called before it has been defined. [...]


    No: You need a declaration, but the declaration is not
    required to provide a prototype. (Under C90 rules, even
    the declaration is sometimes optional.)

    Prototypes are a Good Thing; I cannot think of a case
    where a prototype-less declaration wouldn't be improved by
    adding a prototype. However, the only time a prototype is
    actually required is when the function has a variable-length
    argument list. All fixed-length prototypes can be omitted,
    if you've got masochistic tendencies and are willing to suffer
    opprobrium from others who work with your awful code.

    --
    Eric Sosman, Jul 19, 2005
    #9
  10. DevarajA

    John Bode Guest

    Eric Sosman wrote:
    > John Bode wrote:
    > >
    > > DevarajA wrote:
    > >
    > >>If a function is visible everywhere, even out the file where it is
    > >>declared and defined, why should i write prototypes?
    > >>--
    > >>Devaraja (Xdevaraja87^gmail^c0mX)
    > >>Linux Registerd User #338167
    > >>http://counter.li.org

    > >
    > >
    > > You need to have a prototype declaration in scope if the function is
    > > being called before it has been defined. [...]

    >
    > No: You need a declaration, but the declaration is not
    > required to provide a prototype. (Under C90 rules, even
    > the declaration is sometimes optional.)
    >
    > Prototypes are a Good Thing; I cannot think of a case
    > where a prototype-less declaration wouldn't be improved by
    > adding a prototype. However, the only time a prototype is
    > actually required is when the function has a variable-length
    > argument list. All fixed-length prototypes can be omitted,
    > if you've got masochistic tendencies and are willing to suffer
    > opprobrium from others who work with your awful code.
    >
    > --
    >


    You're right. That first sentence should be amended to, "you need to
    have a declaration in scope (preferably using prototype syntax in favor
    of the old K&R-style syntax) ..."
    John Bode, Jul 19, 2005
    #10
  11. DevarajA

    Flash Gordon Guest

    DevarajA wrote:
    > osmium ha scritto:
    >
    >> "DevarajA" writes:
    >>
    >>
    >>> so why this works and only gives "implicit declaration" warnings?
    >>>
    >>> int main()
    >>> {
    >>> a(8,9);
    >>> b(9,9.5);
    >>> c(9.5,10);
    >>> return 0;
    >>> }
    >>> int a(int x, int y){return 0;}
    >>> int b(int x, double y){return 0;}
    >>> int c(double x, int y){return 0;}

    >>
    >> There was a time when something called K&R C was a more or less de
    >> facto standard. Before there was a real standard. It assumed that
    >> everything was int. Your compiler is in a mode such that it accepts
    >> the old dialect.


    It was not removed from the C89 standard, only deprecated.

    > So for that old standard a call to a undeclared function f1 is an
    > implicit declaration (as int f1(...))?


    No, definitely not. It assumes are return type of in and a FIXED number
    and types of arguments (after they have undergone the default argument
    promotions) based on the first call it sees. Although this works if you
    get it exactly right, it does not work if:
    1) The function returns something other than int
    2) You don't get the list of arguments right
    3) the functions has varargs (, ...) parameters
    4) The function takes parameters of types that will be promoted (e.g. char)

    The compiler does not have to diagnose (generate error or warning) for
    ANY of these problems. So you should always make sure you have the
    correct prototype in scope.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Jul 19, 2005
    #11
  12. DevarajA wrote on 19/07/05 :
    > If a function is visible everywhere, even out the file where it is declared
    > and defined, why should i write prototypes?


    You mean separated prototypes ? To be sure that you are using the
    function correctily (type and number of parameters essentially)

    The Good Way(c) is

    declare the function in a header (.h) as a separated prototype:

    /* f.h */
    int f(char const *s);

    define the function in a source file (.c) and include the prototype
    (for consistency):

    /* f.c */
    #include "f.h"

    int f(char const *s)
    {
    }

    Include the header (hence the prototype) each time you use the function
    elswhere:

    /* x.c */
    #include "f.h"

    ....
    {
    int a = f ("123");
    }

    Of course the header, like any header, is protected against multiple
    inclusions:

    #ifndef H_F
    #define H_F
    ....
    #endif /* guard */



    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    "Mal nommer les choses c'est ajouter du malheur au
    monde." -- Albert Camus.
    Emmanuel Delahaye, Jul 20, 2005
    #12
  13. On Tue, 19 Jul 2005 13:15:45 GMT, in comp.lang.c , DevarajA
    <> wrote:

    >If a function is visible everywhere, even out the file where it is
    >declared and defined, why should i write prototypes?


    Having external linkage ie being visible to the linker everywhere does
    not mean also visible to the compiler. Nor that it knows the types of
    the arguments or even the function's return type. You need to
    prototype the fn in order for the compiler to know that.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jul 20, 2005
    #13
  14. On Tue, 19 Jul 2005 20:01:05 +0100, Flash Gordon
    <> wrote:

    > DevarajA wrote:
    > > osmium ha scritto:
    > >
    > >> "DevarajA" writes:
    > >>
    > >>
    > >>> so why this works and only gives "implicit declaration" warnings?
    > >>>
    > >>> int main()
    > >>> {
    > >>> a(8,9);
    > >>> b(9,9.5);
    > >>> c(9.5,10);
    > >>> return 0;
    > >>> }
    > >>> int a(int x, int y){return 0;}
    > >>> int b(int x, double y){return 0;}
    > >>> int c(double x, int y){return 0;}
    > >>
    > >> There was a time when something called K&R C was a more or less de
    > >> facto standard. Before there was a real standard. It assumed that
    > >> everything was int. Your compiler is in a mode such that it accepts
    > >> the old dialect.

    >
    > It was not removed from the C89 standard, only deprecated.
    >

    Nit: Implicit int, and implicit function declaration, which is
    slightly different but related and is what is actually at issue here,
    were _not_ deprecated in C89/90, but were deleted in C99.
    _Nonprototype_ declarations and definitions of functions, aka K&R1 or
    old-style, _were_ deprecated (actually, called obsolescent) in C89/90
    and are still obsolescent but still present in C99.

    > > So for that old standard a call to a undeclared function f1 is an
    > > implicit declaration (as int f1(...))?

    >
    > No, definitely not. It assumes are return type of in and a FIXED number
    > and types of arguments (after they have undergone the default argument
    > promotions) based on the first call it sees. Although this works if you
    > get it exactly right, it does not work if:
    > 1) The function returns something other than int
    > 2) You don't get the list of arguments right
    > 3) the functions has varargs (, ...) parameters
    > 4) The function takes parameters of types that will be promoted (e.g. char)
    >


    It is not required to work if you get these wrong, but it _might_.

    In particular on many systems, but not all, variadic and nonvariadic
    calls are compatible so violating 3 won't fail; and on I think most
    systems the calling sequence promotes narrow types even where C
    doesn't so violating 4 at least for integers won't actually fail.

    > The compiler does not have to diagnose (generate error or warning) for
    > ANY of these problems. So you should always make sure you have the
    > correct prototype in scope.


    The implementation is not required to diagnose wrong nonprototyped
    calls, and the compiler in particular is almost never able to; in some
    rare systems the linker can. Historically there was a separate tool,
    lint, which did check, and there are still versions around, but using
    prototypes is usually easier and certainly more standard.

    Note particularly the phrasing 'correct prototype'. The compiler will
    check and conform calls against the prototype provided, but cannot by
    itself check the prototype declaration against the definition if in a
    different translation unit ~ source file. For this reason if you
    follow the normal practice of implementing a module (one or several
    related 'public' functions, perhaps plus other stuff) in a foo.c file
    and putting the declarations therefor in foo.h for other modules like
    bar.c to #include, you should also #include foo.h in foo.c. This seems
    redundant, since the compiler knows the types from the definitions,
    but it will (is required to) check that the types in the definition(s)
    are compatible with those in the declaration(s) that clients are
    using; if you change the definition but forget to update the
    declaration, or vice versa (IME less likely), this will catch it.

    - David.Thompson1 at worldnet.att.net
    Dave Thompson, Jul 25, 2005
    #14
    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. Lars Hedström

    Prototypes of html-pages

    Lars Hedström, Apr 8, 2004, in forum: HTML
    Replies:
    3
    Views:
    373
    Jim Roberts
    Apr 8, 2004
  2. Paul Davis
    Replies:
    2
    Views:
    304
    Paul Davis
    Jul 15, 2003
  3. Dave Vandervies

    Default arguments and prototypes

    Dave Vandervies, Oct 2, 2003, in forum: C++
    Replies:
    5
    Views:
    459
    Victor Bazarov
    Oct 3, 2003
  4. Denis Remezov

    order of const in function prototypes

    Denis Remezov, Jun 30, 2004, in forum: C++
    Replies:
    7
    Views:
    423
    John Harrison
    Jun 30, 2004
  5. fb

    Prototypes

    fb, Sep 2, 2003, in forum: C Programming
    Replies:
    14
    Views:
    738
    Dave Thompson
    Sep 8, 2003
Loading...

Share This Page