return value?

[Bill Cunningham]

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

 

[vippstar]

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.

 

[Keith Thompson]

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>.

 

[Bill Cunningham]

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);
}

 

[Bill Cunningham]

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

 

[Bill Cunningham]

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

 

[fjblurt]

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.

That's not correct. fgetc will return EOF (which on your system, like
many others, has a numerical value of -1) for either end-of-file or
error. You need to call the feof() or ferror() functions to decide
which one it was.

Incidentally, you may want to use getc() and putc() instead of fgetc()
and fputc(). The former are macros and will be a little bit faster.
Also, since getc()/putc() are more commonly used than fgetc()/fputc(),
another programmer reading your code will recognize them more
immediately.

 

[Bill Cunningham]

What makes you think that?

I assumed again. I guess that's part of my problem. -1 I always thought
was an error code that's why I didn't quite understand what was happening at
first. I didn't know EOF was -1. I thought 0 or 1 or some positive integer
was a non-error and a negative an error. That's what I've come across in
most C returns and linux sys call returns.

I've really started mastering *some* C functions here lately. The things
I don't get is pointer arithmetic and small semantics. Now I'm going OT..

Anyway Richard my first impression with -1 was that there was an error.

Bill

 

[Bill Cunningham]

That's not correct. fgetc will return EOF (which on your system, like
many others, has a numerical value of -1) for either end-of-file or
error. You need to call the feof() or ferror() functions to decide
which one it was.

Incidentally, you may want to use getc() and putc() instead of fgetc()
and fputc(). The former are macros and will be a little bit faster.
Also, since getc()/putc() are more commonly used than fgetc()/fputc(),
another programmer reading your code will recognize them more
immediately.

What about a case where I wanted to write over a file with a char say
'\0'. I can set a='\0'; with fputc and use fputc(a,FILE*); and write over a
file I wanted to delete. Maybe several times for secure deletion and then
erase the file '\0' was written to. Can you do that with putc ?

Bill

 

[Bill Cunningham]

Yes - putc and fputc have the same interface and the same purpose. Unless
you have an excellent reason to use fputc (and you don't), you might as
well use putc.

I gotcha. Out of curiousity, what would be a good reason to fpuc/fgetc ?
I suppose the same goes for fgets/fputs and gets/puts ? I know that gets is
dangerous.

Bill

 

[Keith Thompson]

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.

You do not surmise correctly.

Stop guesing, stop asking questions, and read the documentation.

 

[fjblurt]

What about a case where I wanted to write over a file with a char say
'\0'. I can set a='\0'; with fputc and use fputc(a,FILE*); and write over a
file I wanted to delete. Maybe several times for secure deletion and then
erase the file '\0' was written to.

How many times do you usually overwrite a text file
to make sure that you got the right text in there?

Can you do that with putc ?

putc is defined in terms of fputc.

N869
7.19.7.8 The putc function

[#2] The putc function is equivalent to fputc, except that
if it is implemented as a macro, it may evaluate stream more
than once, so that argument should never be an expression
with side effects.

This makes it sound like the character c to be written will *not* be
evaluated more than once. I didn't know that, but it's useful if
true, since it could be convenient to have a side effect there. E.g.
putc(buf[i++], stream). It is harder to think of a realistic example
where you would use an expression with side effects for stream.

 

[Ben Bacarisse]

"Gordon Burditt" <[email protected]> wrote in message

No special device file are involved here. I didn't know EOF
meant -1.

That's odd. Your code was (roughly):

while ((c = fgetc(in)) != EOF)
fputc(c, out);
printf("%d\n", c);

and you asked your question because this printf printed -1. You only
get to the printf if c != EOF is false, so you had reasonable evidence
that EOF is -1 (on your implementation). Programming will be full of
surprises if you don't start thinking like this.

 

[Martien Verbruggen]

while ((i = fgetc(fr)) != EOF)
fputc(a, fw);

Note, apart from the other remarks, that you read a character into i,
but you write what's in a. You never initialised a. I doubt that this is
what you intended to do.

Martien

 

[Default User]

"Bill Cunningham" <[email protected]> writes:

[blah blah]

Programming will be full of
surprises if you don't start thinking like this.

Or thinking, period.




Brian

 

[Nick Keighley]

You do not surmise correctly.

Stop guesing, stop asking questions, and read the documentation.

http://www.dinkumware.com/c99.aspx

or just type the name of the function into google

 

[Keith Thompson]

http://www.dinkumware.com/c99.aspx

or just type the name of the function into google

He has a copy of K&R2. I've advised him to use that as his only
reference. This isn't advice I'd give to C programmers in general,
but in his case, I think having multiple references isn't going to be
helpful.

 

[Nick Keighley]

He has a copy of K&R2.  I've advised him to use that as his only
reference.  This isn't advice I'd give to C programmers in general,
but in his case, I think having multiple references isn't going to be
helpful.

yes you're probably right. But Bill baffles me. If you've got
a bad memory (as he sometimes claim) then you use every reference you
can lay your hands on- you write everything down. I have a bad
memory so I *know* that's how to handle it (I just can't remember
where the references are...). So to me online stuff is
great I just copy-paste the function sig into the source code.
That means I'm goinf to get the arguments in the right order.
Pre-internet (or access to the inter-net anyway) I used either
a photocopy of the library appendix from the standard or H&S
(I considered H&S to be better for the libvrary than K&R)

 

[Barry Schwarz]

#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);
}

You claim this code copies files and works fine. Yet this code never
writes any of the characters from the input file to the output file.
So the question is - which of the concepts, "copies" or "works fine",
do you have your own meaning for so that when the copy does not look
like the original you are still satisfied?

Even if you correct the error in the call to fputc, this code will not
work correctly on a Windows system or any other that performs
substitutions for '\n' .

You might also want to make sure you don't request input or output for
a file when fopen failed for that file.