fgets prototype doesn't include const?

Discussion in 'C Programming' started by jaime, Aug 13, 2007.

  1. jaime

    jaime Guest

    Hi all.

    According to the fgets wikipedia page, its prototype is:

    char* fgets(char *string, int length, FILE * stream)

    Given that fgets never assigns to the first parameter (the char
    pointer), could the prototype also have been defined as:

    char* fgets(char * const string, int length, FILE * stream)

    Am I missing something here? (or is it really that "const"s are frequently
    omitted?)

    TIA, Jaime :)
     
    jaime, Aug 13, 2007
    #1
    1. Advertising

  2. jaime

    Chris Dollin Guest

    jaime wrote:

    > According to the fgets wikipedia page, its prototype is:
    >
    > char* fgets(char *string, int length, FILE * stream)


    Yes.

    > Given that fgets never assigns to the first parameter (the char
    > pointer), could the prototype also have been defined as:
    >
    > char* fgets(char * const string, int length, FILE * stream)


    Doesn't make any difference.

    > Am I missing something here?


    Putting that `const` in the prototype is irrelevant. It makes a
    difference in the function /definition/, where it makes the
    pointer un-assignableto, but that's not of interest in the
    prototype declaration, since one can't assign to the parameter
    anyway [1].

    [1] Apart from the initialisation on the call, of course.

    --
    Hewlett-Packard Limited registered office: Cain Road, Bracknell,
    registered no: 690597 England Berks RG12 1HN
     
    Chris Dollin, Aug 15, 2007
    #2
    1. Advertising

  3. jaime said:

    > Hi all.
    >
    > According to the fgets wikipedia page, its prototype is:
    >
    > char* fgets(char *string, int length, FILE * stream)
    >
    > Given that fgets never assigns to the first parameter (the char
    > pointer), could the prototype also have been defined as:
    >
    > char* fgets(char * const string, int length, FILE * stream)
    >
    > Am I missing something here? (or is it really that "const"s are
    > frequently omitted?)


    You are indeed missing something. It is not guaranteed that fgets never
    assigns to the first parameter, and it wouldn't matter if it did, since
    C is pass-by-value, so there's no particular value in making the input
    parameter const. To do so would place an entirely unnecessary
    restriction on the implementation of fgets.

    For example, it might want to work something like this:

    #include <stdio.h>

    /* beware - this is just a sketch, not a tested implementation */
    char *fgets(char *_b, int _n, FILE *_f)
    {
    char *_r = _b;
    while(_n-- > 1 && (*_b = getc(_f)) != EOF)
    {
    ++_b; /* _b is modified here - this is a local change, affecting
    only the object owned by fgets - it doesn't have any
    effect on the value of the object used in the argument
    expression during the call. */
    }
    if(*_b != EOF)
    {
    *_b = '\0';
    }
    else
    {
    _r = NULL;
    }
    return _r;
    }

    If _b were const-qualified, this code would not compile.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Aug 15, 2007
    #3
  4. jaime

    jxh Guest

    On Aug 15, 4:41 am, Richard Heathfield <> wrote:
    [snip]
    >
    > #include <stdio.h>
    >
    > /* beware - this is just a sketch, not a tested implementation */


    Good thing for the warning. A couple of fixups are needed.

    > char *fgets(char *_b, int _n, FILE *_f)
    > {
    > char *_r = _b;

    int _c;
    while(_n-- > 1 && (_c = getc(_f)) != EOF)
    > {

    *_b++ = _c;
    > /* _b is modified here - this is a local change, affecting
    > only the object owned by fgets - it doesn't have any
    > effect on the value of the object used in the argument
    > expression during the call. */

    if (_c == '\n')
    {
    break;
    }
    > }

    if(_c != EOF)
    > {
    > *_b = '\0';
    > }
    > else
    > {
    > _r = NULL;
    > }
    > return _r;
    >
    > }


    -- James
     
    jxh, Aug 15, 2007
    #4
  5. jxh said:

    > On Aug 15, 4:41 am, Richard Heathfield <> wrote:
    > [snip]
    >>
    >> #include <stdio.h>
    >>
    >> /* beware - this is just a sketch, not a tested implementation */

    >
    > Good thing for the warning.


    Nevertheless, good catches.

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Aug 15, 2007
    #5
  6. jaime

    pete Guest

    jaime wrote:
    >
    > Hi all.
    >
    > According to the fgets wikipedia page, its prototype is:
    >
    > char* fgets(char *string, int length, FILE * stream)
    >
    > Given that fgets never assigns to the first parameter (the char
    > pointer), could the prototype also have been defined as:
    >
    > char* fgets(char * const string, int length, FILE * stream)
    >
    > Am I missing something here?
    > (or is it really that "const"s are frequently omitted?)


    What you are missing is that consts
    are always omitted on the parameters.

    There are no const qualified parameters
    in any standard library function,
    for reasons that Richard Heathfield has
    already explained elsewhere in this thread.

    --
    pete
     
    pete, Aug 15, 2007
    #6
  7. jaime

    CBFalconer Guest

    pete wrote:
    > jaime wrote:
    >>
    >> According to the fgets wikipedia page, its prototype is:
    >>
    >> char* fgets(char *string, int length, FILE * stream)
    >>
    >> Given that fgets never assigns to the first parameter (the char
    >> pointer), could the prototype also have been defined as:
    >>
    >> char* fgets(char * const string, int length, FILE * stream)
    >>
    >> Am I missing something here?
    >> (or is it really that "const"s are frequently omitted?)

    >
    > What you are missing is that consts are always omitted on the
    > parameters. There are no const qualified parameters in any
    > standard library function, for reasons that Richard Heathfield
    > has already explained elsewhere in this thread.


    You are mistaken. Here is an example from N869:

    7.21.2.3 The strcpy function

    Synopsis
    [#1]
    #include <string.h>
    char *strcpy(char * restrict s1,
    const char * restrict s2);

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 16, 2007
    #7
  8. CBFalconer said:

    > pete wrote:

    <snip>
    >>
    >> What you are missing is that consts are always omitted on the
    >> parameters. There are no const qualified parameters in any
    >> standard library function, for reasons that Richard Heathfield
    >> has already explained elsewhere in this thread.

    >
    > You are mistaken. Here is an example from N869:
    >
    > 7.21.2.3 The strcpy function
    >
    > Synopsis
    > [#1]
    > #include <string.h>
    > char *strcpy(char * restrict s1,
    > const char * restrict s2);


    You are mistaken. The constness here applies to the thing pointed at,
    not the pointer itself (i.e. the parameter, which is what pete was
    talking about).

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Aug 16, 2007
    #8
  9. On Aug 15, 10:15 pm, CBFalconer <> wrote:
    > pete wrote:
    > > What you are missing is that consts are always omitted on the
    > > parameters. There are no const qualified parameters in any
    > > standard library function, for reasons that Richard Heathfield
    > > has already explained elsewhere in this thread.

    >
    > You are mistaken. Here is an example from N869:
    >
    > 7.21.2.3 The strcpy function
    >
    > Synopsis
    > [#1]
    > #include <string.h>
    > char *strcpy(char * restrict s1,
    > const char * restrict s2);


    While that prototype does use the "const" keyword, the parameter
    itself is not constant. In this instance, it means that the characters
    pointed to by "s2" will not be modified. The others were discussing
    definitions such as:

    char *strcpy(char * const restrict s1, const char * const restrict
    s2);

    in which the values of the parameters themselves would not be able to
    be changed in the implementation of the function, which is kind of a
    ridiculous restriction, seeing as it does not affect the calling code.
     
    Justin Spahr-Summers, Aug 16, 2007
    #9
  10. jaime

    CBFalconer Guest

    Richard Heathfield wrote:
    > CBFalconer said:
    >> pete wrote:
    >>

    > <snip>
    >>>
    >>> What you are missing is that consts are always omitted on the
    >>> parameters. There are no const qualified parameters in any
    >>> standard library function, for reasons that Richard Heathfield
    >>> has already explained elsewhere in this thread.

    >>
    >> You are mistaken. Here is an example from N869:
    >>
    >> 7.21.2.3 The strcpy function
    >>
    >> Synopsis
    >> [#1]
    >> #include <string.h>
    >> char *strcpy(char * restrict s1,
    >> const char * restrict s2);

    >
    > You are mistaken. The constness here applies to the thing pointed
    > at, not the pointer itself (i.e. the parameter, which is what
    > pete was talking about).


    I don't even consider that, since parameters are by value, and any
    const attribute can't possibly affect the caller in any way. To my
    mind your restriction is totally useless.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 16, 2007
    #10
  11. CBFalconer <> writes:
    > Richard Heathfield wrote:
    >> CBFalconer said:
    >>> pete wrote:

    >> <snip>
    >>>>
    >>>> What you are missing is that consts are always omitted on the
    >>>> parameters. There are no const qualified parameters in any
    >>>> standard library function, for reasons that Richard Heathfield
    >>>> has already explained elsewhere in this thread.
    >>>
    >>> You are mistaken. Here is an example from N869:
    >>>
    >>> 7.21.2.3 The strcpy function
    >>>
    >>> Synopsis
    >>> [#1]
    >>> #include <string.h>
    >>> char *strcpy(char * restrict s1,
    >>> const char * restrict s2);

    >>
    >> You are mistaken. The constness here applies to the thing pointed
    >> at, not the pointer itself (i.e. the parameter, which is what
    >> pete was talking about).

    >
    > I don't even consider that, since parameters are by value, and any
    > const attribute can't possibly affect the caller in any way.


    Yes, that's exactly the point. The OP was asking why fgets is declared as
    char* fgets(char *string, int length, FILE * stream);
    rather than
    char* fgets(char * const string, int length, FILE * stream);

    Both pete and Richard were answering that question. I'll grant you
    that pete's statement that "[t]here are no const qualified parameters
    in any standard library function" was worded imprecisely (it happens).

    --
    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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 16, 2007
    #11
  12. jaime

    pete Guest

    CBFalconer wrote:
    >
    > Richard Heathfield wrote:
    > > CBFalconer said:
    > >> pete wrote:
    > >>

    > > <snip>
    > >>>
    > >>> What you are missing is that consts are always omitted on the
    > >>> parameters. There are no const qualified parameters in any
    > >>> standard library function, for reasons that Richard Heathfield
    > >>> has already explained elsewhere in this thread.
    > >>
    > >> You are mistaken. Here is an example from N869:
    > >>
    > >> 7.21.2.3 The strcpy function
    > >>
    > >> Synopsis
    > >> [#1]
    > >> #include <string.h>
    > >> char *strcpy(char * restrict s1,
    > >> const char * restrict s2);

    > >
    > > You are mistaken. The constness here applies to the thing pointed
    > > at, not the pointer itself (i.e. the parameter, which is what
    > > pete was talking about).

    >
    > I don't even consider that, since parameters are by value, and any
    > const attribute can't possibly affect the caller in any way. To my
    > mind your restriction is totally useless.


    Each word of your post is within my vocabulary,
    but the order in which you've arranged them,
    makes no sense to me.

    Do you agree or disagree with:
    "There are no const qualified parameters
    in any standard library function"
    ?

    Are you using this definition of "parameter"?:

    N869
    3.16
    [#1] parameter
    formal parameter
    formal argument (deprecated)

    object declared as part of a function declaration or
    definition that acquires a value on entry to the function

    --
    pete
     
    pete, Aug 16, 2007
    #12
    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. Replies:
    11
    Views:
    1,151
  2. Javier
    Replies:
    2
    Views:
    621
    James Kanze
    Sep 4, 2007
  3. Andreas Bogenberger
    Replies:
    3
    Views:
    1,003
    Andreas Bogenberger
    Feb 22, 2008
  4. 0m
    Replies:
    26
    Views:
    1,171
    Tim Rentsch
    Nov 10, 2008
  5. Jonathan Dodds

    JScript/ASP prototype doesn't work from an include?

    Jonathan Dodds, Mar 17, 2005, in forum: ASP General
    Replies:
    4
    Views:
    297
    Jonathan Dodds
    Mar 17, 2005
Loading...

Share This Page