By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,720 Members | 2,135 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,720 IT Pros & Developers. It's quick & easy.

fgets prototype doesn't include const?

P: n/a
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 :-)
Aug 15 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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

Aug 15 '07 #2

P: n/a
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
Aug 15 '07 #3

P: n/a
jxh
On Aug 15, 4:41 am, Richard Heathfield <r...@see.sig.invalidwrote:
[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

Aug 15 '07 #4

P: n/a
jxh said:
On Aug 15, 4:41 am, Richard Heathfield <r...@see.sig.invalidwrote:
[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
Aug 15 '07 #5

P: n/a
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
Aug 15 '07 #6

P: n/a
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

Aug 16 '07 #7

P: n/a
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
Aug 16 '07 #8

P: n/a
On Aug 15, 10:15 pm, CBFalconer <cbfalco...@yahoo.comwrote:
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.

Aug 16 '07 #9

P: n/a
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

Aug 16 '07 #10

P: n/a
CBFalconer <cb********@yahoo.comwrites:
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) ks***@mib.org <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"
Aug 16 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.