the buffer question of the stdio

S

sunway

i have written a small program, it turns out to be wrong,
while(read()!=EOF){
read();
read();
read();

}
so,when read==EOF,the next read() will read a -1, and the program will go
infinitely.

but,when i use ^c to abort the program,the output file's size is
always 4096 bytes.why? notice that the program is always writing
that file. the buffer should be flushed again and again.
 
E

Eric Sosman

sunway said:
i have written a small program, it turns out to be wrong,
while(read()!=EOF){
read();
read();
read();

}
so,when read==EOF,the next read() will read a -1, and the program will go
infinitely.

but,when i use ^c to abort the program,the output file's size is
always 4096 bytes.why? notice that the program is always writing
that file. the buffer should be flushed again and again.

1: There is no read() function in C. <OT> There is
a read() function in POSIX, but it takes three arguments
rather than zero and doesn't return EOF at end-of-file. </OT>

2: I don't "notice that the program is always writing"
anything at all. There are no output operations anywhere in
what you've shown. <OT> Unless, of course, the non-POSIX
read() function you've implemented performs output. </OT>

3: Nothing in the code you've shown has anything to do
with stdio.

4: <OT> Nothing in the code you've shown has anything to
do with buffering. </OT>

5: The fact that your program "turns out to be wrong" does
not surprise me in the slightest. You don't have the faintest
idea of what you're doing. And, given the non-information
you've provided, neither do I.
 
S

sunway

sorry,i have shown only a brief of the code
the code is not written by me,a fellow give it to me and ask me for help

here is the total program:

#include "stdio.h"
#include "stdlib.h"
#include "math.h"
main(){
int opt,i;
char ch[4],cht,*p;
//p=ch;
FILE *fpin,*fpout;
int ch_opt(char ch_option);
/**************/

/**************/
fpin=fopen("blink.hex", "rb");
fpout=fopen("blink.dat","w");
/**************/
while(cht!=EOF){
~~~~~~~here is the problem,the program will go infinitely,but
the output file"blink.dat" would not larger than 4096

for(i=0;i<4;){
cht=fgetc(fpin);
opt=ch_opt(cht);
if(opt != 3){
ch=cht;
i++;}

//printf("%d ",opt);
//printf("%d\n",cht);
//getchar();
}
i=0;
fputc('0',fpout);
fputc('x',fpout);
fputc(ch[0],fpout);
fputc(ch[1],fpout);
fputc(ch[2],fpout);
fputc(ch[3],fpout);
fputc(',',fpout);
}
//return 0;
}

int ch_opt(char ch_option)
{
if(ch_option >= '0' && ch_option <='9')
return 1;
else if(ch_option >= 'A' && ch_option <='Z')
return 2;
else
return 3;
}
 
A

Artie Gold

sunway said:
sorry,i have shown only a brief of the code
the code is not written by me,a fellow give it to me and ask me for help

here is the total program:

#include "stdio.h"
#include "stdlib.h"
#include "math.h"
main(){
int opt,i;
char ch[4],cht,*p;

You must make `cht' an *int*, otherwise it can *never* be equal to EOF.
//p=ch;
FILE *fpin,*fpout;
int ch_opt(char ch_option);
Function prototypes should usually be at file scope.
/**************/

/**************/
fpin=fopen("blink.hex", "rb");
fpout=fopen("blink.dat","w");
/**************/
while(cht!=EOF){
Here, `cht' is uninitialized and could contain *anything* (well,
anything that will fit in a `char' -- which, as mentioned above,
excludes EOF.
~~~~~~~here is the problem,the program will go infinitely,but
the output file"blink.dat" would not larger than 4096

for(i=0;i<4;){
cht=fgetc(fpin);
opt=ch_opt(cht);
if(opt != 3){
ch=cht;
i++;}

//printf("%d ",opt);
//printf("%d\n",cht);
//getchar();
}
i=0;
fputc('0',fpout);
fputc('x',fpout);
fputc(ch[0],fpout);
fputc(ch[1],fpout);
fputc(ch[2],fpout);
fputc(ch[3],fpout);
fputc(',',fpout);
}
//return 0;
}

int ch_opt(char ch_option)
{
if(ch_option >= '0' && ch_option <='9')
return 1;
else if(ch_option >= 'A' && ch_option <='Z')


This is not guaranteed to work the way you want (though it will if your
character set is ASCII).
return 2;
else
return 3;
}

HTH,
--ag
 
K

Keith Thompson

Jordan Abel said:
Yes, it should, but it's not required to.

According to the standard,
#include <foo.h>
searches for a "header" (which isn't necessarily a file) in a sequence
of implementation-defined places.
#include "foo.h"
searches for a file named "foo.h" in an implementation-defined manner.
If that search fails or is not supported, the directive is then
reprocessed as if it were
#include <foo.h>

So
#include "stdio.h"
is *nearly* equivalent to
#include <stdio.h>
but if there happens to be a file named "stdio.h" somewhere in the
search path, that file will be included instead of the standard
header. Using the <> form avoids this possibility.
 
J

Jordan Abel

According to the standard,
#include <foo.h>
searches for a "header" (which isn't necessarily a file) in a sequence
of implementation-defined places.
#include "foo.h"
searches for a file named "foo.h" in an implementation-defined manner.
If that search fails or is not supported, the directive is then
reprocessed as if it were
#include <foo.h>

So
#include "stdio.h"
is *nearly* equivalent to
#include <stdio.h>
but if there happens to be a file named "stdio.h" somewhere in the
search path, that file will be included instead of the standard
header. Using the <> form avoids this possibility.

There can be benefits to using "", though - say, have #include
"stdbool.h", and conditionally generate a local header that contains the
appropriate definitions for pre-c99 systems
 
O

Old Wolf

Artie said:
sunway said:
char ch[4],cht,*p;
while(cht!=EOF){

You must make `cht' an *int*, otherwise it can *never* be equal to EOF.

Actually it can be equal to EOF. EOF can be any negative value
but is usually -1, and -1 is in the range of char if char is signed.

The problem with 'cht' being a char is that it cannot correctly
represent values greater than CHAR_MAX, and in the OP's
case, if getchar() returns 255 then cht will end up with the
value -1, which will test equal to EOF.

The OP should change ch[] to 'int' as well.
 
K

Keith Thompson

Old Wolf said:
Artie said:
sunway said:
char ch[4],cht,*p;
while(cht!=EOF){

You must make `cht' an *int*, otherwise it can *never* be equal to EOF.

Actually it can be equal to EOF. EOF can be any negative value
but is usually -1, and -1 is in the range of char if char is signed.

The problem with 'cht' being a char is that it cannot correctly
represent values greater than CHAR_MAX, and in the OP's
case, if getchar() returns 255 then cht will end up with the
value -1, which will test equal to EOF.

That's the problem with 'cht' being a char if plain char happens to be
signed. If plain char is unsigned, the problem is that it can never
be equal to EOF. (I'm deliberately ignoring the possibility of
sizeof(int)==1.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top