Confusing Prototype

Confusing Prototype

[James Colannino]

Hey everyone.  I was looking at the prototype for fgets and noticed the 
following:

char *fgets(char *s, int size, FILE *stream);

I'm confused because it says that it returns a pointer to a character, 
but at the same time it stores a string at the address pointed to by 
char *s, so why does it also need to return a pointer?  I'm confused.  
Thanks in advance.

James

Re: Confusing Prototype

[_z33]

James Colannino wrote:
> Hey everyone.  I was looking at the prototype for fgets and noticed the 
> following:
> 
> char *fgets(char *s, int size, FILE *stream);
> 
> I'm confused because it says that it returns a pointer to a character, 
> but at the same time it stores a string at the address pointed to by 
> char *s, so why does it also need to return a pointer?  I'm confused.  

   please correct me if I'm wrong. As far as I know, you need a 
mechanism to find out if fgets, executed perfectly or not, and that's 
the primary reason it returns a value. When fgets fails to read from the 
stream specified it returns a null pointer to indicate the error. The 
string in the argument list of the function however, will have the value 
till which execution proceeded without error. (hope I'm right about this)

   If in case the returning pointer, was avoided, then the error 
couldn't be properly indicated. And the only way will be to modify the 
input string container itself. This could create an ambiguity, if the 
input file or stream had nothing but a null value. The programmer might 
not be able to differentiate whether an error occured or whether input 
was null.

#include <stdio.h>

int main (int argc, char *argv[])
{
     /* for file access */
     FILE *fp;

     /* array to store some 5 characters */
     char array[5] = {'\0'};

     /* to store the return value */
     char *status;

     /* open the file for reading */
     if ((fp = fopen ("testFile.txt", "r")) == NULL)
     {
         /* display error information and exit */
         fprintf (stderr, "Error: file read failed. \n");
         exit (1);
     }

     /* read twice */
     status = fgets (array, sizeof (array), fp);
     status = fgets (array, sizeof (array), fp);

     /*
      * without the return value fgets can't display the error
      * encountered.
      * the input string passed is never touched when an error occurs.
      */

     /* close file */
     fclose (fp);

     /* display the array value */
     printf ("array: %s \n", array);

     /* display the status returned */
     printf ("status: %s \n", status);

     return (0);
}

Sorry, if I have confused you.

_z33
-- 
I love TUX; well... that's an understatement :)

Re: Confusing Prototype

[Steve Graegert]

On 9/12/05, _z33 <timid.Gentoo@gmail.com> wrote:
> James Colannino wrote:
> > Hey everyone.  I was looking at the prototype for fgets and noticed the
> > following:
> >
> > char *fgets(char *s, int size, FILE *stream);
> >
> > I'm confused because it says that it returns a pointer to a character,
> > but at the same time it stores a string at the address pointed to by
> > char *s, so why does it also need to return a pointer?  I'm confused.
> 
>   please correct me if I'm wrong. As far as I know, you need a
> mechanism to find out if fgets, executed perfectly or not, and that's
> the primary reason it returns a value. When fgets fails to read from the
> stream specified it returns a null pointer to indicate the error. The
> string in the argument list of the function however, will have the value
> till which execution proceeded without error. (hope I'm right about this)
> 
>   If in case the returning pointer, was avoided, then the error
> couldn't be properly indicated. And the only way will be to modify the
> input string container itself. This could create an ambiguity, if the
> input file or stream had nothing but a null value. The programmer might
> not be able to differentiate whether an error occured or whether input
> was null.

Sorry, I do not fully agree.  NULL is also returned when the system
encountered EOF.   SUSv3 says that if EOF or an error occurred the
stream's EOF/error indicator is set, which means that to make sure
what happened you will have to call ferror and feof anyway.  In both
cases the buffer is left unchanged.

From this point of view, returning an int indicating an error and EOF
with a value of 0 and the number of bytes read otherwise would be
sufficient.  One could then write

	while (fgets(buf, BUFSIZE, stream) > 0)  { /* do some stuff */ }

For me, it is an academic discussion and I can live with the current
solution quite well.  Besides this, I have had the opportunity to
implement parts of an IO library for an embedded project and we have
chosen not to return a pointer to the input buffer but the number of
bytes actually read or 0 on EOF or error.  It was possible since
everything was written from scratch, so nothing broke.

Regards

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409

Re: Confusing Prototype

[_z33]

Steve Graegert wrote:
> 
> Sorry, I do not fully agree. 

   I knew I must have gone wrong somewhere ;-)

> NULL is also returned when the system
> encountered EOF.   SUSv3 says that if EOF or an error occurred the
> stream's EOF/error indicator is set, which means that to make sure
> what happened you will have to call ferror and feof anyway.  In both
> cases the buffer is left unchanged.
> 
> From this point of view, returning an int indicating an error and EOF
> with a value of 0 and the number of bytes read otherwise would be
> sufficient.  One could then write
> 
> 	while (fgets(buf, BUFSIZE, stream) > 0)  { /* do some stuff */ }
> 

   I agree absolutely.

> For me, it is an academic discussion and I can live with the current
> solution quite well.  Besides this, I have had the opportunity to
> implement parts of an IO library for an embedded project and we have
> chosen not to return a pointer to the input buffer but the number of
> bytes actually read or 0 on EOF or error.  It was possible since
> everything was written from scratch, so nothing broke.
   nice solution.

_z33
-- 
I love TUX; well... that's an understatement :)

Re: Confusing Prototype

[Steve Graegert]

On 9/13/05, _z33 <timid.Gentoo@gmail.com> wrote:
> Steve Graegert wrote:
> >
> > Sorry, I do not fully agree.
> 
>    I knew I must have gone wrong somewhere ;-)

You haven't been wrong.  The assumptions you made are quite correct. 
I just disagreed on the fact that a pointer to the input buffer is
returned unconditionally.

Regards

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409