return value?

I have been using fgetc and fputc with a while loop construct to copy
files. It seems to work fine but the thing is I always check for fgetc's RV
and it's always -1. If the program doesn't work right I get -1. Is -1 always
an error code and doesn't it always mean failure?

Bill

On Aug 27, 4:17 am, "Bill Cunningham" <nos...@nspam.com> wrote:
> I have been using fgetc and fputc with a while loop construct to copy
> files. It seems to work fine but the thing is I always check for fgetc's RV
> and it's always -1. If the program doesn't work right I get -1. Is -1 always
> an error code and doesn't it always mean failure?

No. It's EOF (<stdio.h> and others). On your implementation, EOF
happends to be -1.

Bill Cunningham said:

> I have been using fgetc and fputc with a while loop construct to copy
> files. It seems to work fine but the thing is I always check for fgetc's
> RV and it's always -1. If the program doesn't work right I get -1. Is -1
> always an error code and doesn't it always mean failure?

Code, please.

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

> I have been using fgetc and fputc with a while loop construct to copy
>files. It seems to work fine

Did you look at the copied files? Are they filled with the correct
characters or -1? If they are filled with correct characters, then
fgetc() is *NOT* always returning -1.

Read the documentation on fgetc() that should have come with your compiler.

>but the thing is I always check for fgetc's RV
>and it's always -1.

EOF probably has the value of -1 on your system.

>If the program doesn't work right I get -1. Is -1 always
>an error code and doesn't it always mean failure?

I don't consider EOF to be an error code. You can test whether an
error occurred after getting back EOF as a return value by using
ferror(). If you keep reading a file, you'll usually get EOF (real
end-of-file) eventually (with exceptions for non-ordinary files
like /dev/zero or /dev/random). Getting EOF in the wrong place
might indicate an error.

"Bill Cunningham" <nospam@nspam.com> writes:
> I have been using fgetc and fputc with a while loop construct to copy
> files. It seems to work fine but the thing is I always check for fgetc's RV
> and it's always -1. If the program doesn't work right I get -1. Is -1 always
> an error code and doesn't it always mean failure?

You should not have to ask this question. You should be able to
discover the answer without outside help.

Re-read <http://groups.google.com/group/comp.lang.c/msg/6da991ad26d30ed9>.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Bill Cunningham wrote:
> I have been using fgetc and fputc with a while loop construct to copy
> files. It seems to work fine but the thing is I always check for fgetc's RV
> and it's always -1. If the program doesn't work right I get -1. Is -1 always
> an error code and doesn't it always mean failure?

On some implementations, EOF is equal to (-1).
Your code should be checking to see
if the return value is equal to EOF.

--
pete

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:tOSdnUjtRZsyNinV4p2dnAA@bt.com...

> Code, please.

#include <stdio.h>

int main()
{
FILE *fr, *fw;
int i, a;
if ((fr = fopen("bs", "rb")) == NULL) {
puts("open error");
}
if ((fw = fopen("e", "w")) == NULL) {
puts("open error 2");
}
while ((i = fgetc(fr)) != EOF)
fputc(a, fw);
printf("%i\n", i);
fclose(fr);
fclose(fw);
}

"pete" <pfiland@mindspring.com> wrote in message
news:5rudnbS8Wr0FKynVnZ2dnUVZ_rfinZ2d@earthlink.co m...
> On some implementations, EOF is equal to (-1).
> Your code should be checking to see
> if the return value is equal to EOF.
>

Sounds like everything is in order then. It's just that EOF which I'm
sure fgetc reached, has a value of -1. Now if there was an error, the return
value of fgetc wouldn't be -1 if I surmise correctly.

Bill

"Gordon Burditt" <gordonb.xigrr@burditt.org> wrote in message
news:FJqdnVu_Av1HLSnVnZ2dnUVZ_g6dnZ2d@posted.inter netamerica...
>
> Did you look at the copied files? Are they filled with the correct
> characters or -1? If they are filled with correct characters, then
> fgetc() is *NOT* always returning -1.
>
> Read the documentation on fgetc() that should have come with your
> compiler.
>
>
> EOF probably has the value of -1 on your system.
>
> I don't consider EOF to be an error code. You can test whether an
> error occurred after getting back EOF as a return value by using
> ferror(). If you keep reading a file, you'll usually get EOF (real
> end-of-file) eventually (with exceptions for non-ordinary files
> like /dev/zero or /dev/random). Getting EOF in the wrong place
> might indicate an error.

No special device file are involved here. I didn't know EOF meant -1. I
just use the EOF macro. I always thought -1 meant error. I have copied a
file from binary format and written it like a text file so I don't know if
the characters are right or not. So I will try coping a text to text file.

Bill

Bill Cunningham said:

<snip>

> while ((i = fgetc(fr)) != EOF)
> fputc(a, fw);
> printf("%i\n", i);

So you keep copying characters until i gets the value EOF, and then you
stop, and print the value i has. At this point, it is *bound* to have the
value EOF, because for as long as it had any other value, it could never
reach this point in the code.

On your system, EOF happens to be -1, so -1 is what got printed.

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