the buffer question of the stdio

[sunway]

i have written a small program, it turns out to be wrong,
while(read()!=E OF){
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.
--

My name is sunway

[Eric Sosman]

sunway wrote:

i have written a small program, it turns out to be wrong,
while(read()!=E OF){
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.

--
Eric Sosman
es*****@acm-dot-org.invalid

[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("bli nk.hex", "rb");
fpout=fopen("bl ink.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[i]=cht;
i++;}

//printf("%d ",opt);
//printf("%d\n",c ht);
//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;
}
--

free thought,free world

[Artie Gold]

sunway wrote:

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("bli nk.hex", "rb");
fpout=fopen("bl ink.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[i]=cht;
i++;}

//printf("%d ",opt);
//printf("%d\n",c ht);
//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
--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com
http://www.cafepress.com/goldsays
"If you have nothing to hide, you're not trying!"

[Artie Gold]

Artie Gold wrote:

sunway wrote:

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" ....and this should be #include <stdio.h> #include "stdlib.h" #include <stdlib.h> #include "math.h" ....and you're not using this header main(){
int opt,i;
char ch[4],cht,*p;

[snip]

--ag

--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com
http://www.cafepress.com/goldsays
"If you have nothing to hide, you're not trying!"

[Jordan Abel]

On 2006-01-11, Artie Gold <ar*******@aust in.rr.com> wrote:

#include "stdio.h" ...and this should be #include <stdio.h> #include "stdlib.h"

#include <stdlib.h>

Yes, it should, but it's not required to.

[Keith Thompson]

Jordan Abel <ra*******@gmai l.com> writes:

On 2006-01-11, Artie Gold <ar*******@aust in.rr.com> wrote:

#include "stdio.h"

...and this should be #include <stdio.h>

#include "stdlib.h"

#include <stdlib.h>

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.

--
Keith Thompson (The_Other_Keit h) 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.

[Jordan Abel]

On 2006-01-11, Keith Thompson <ks***@mib.or g> wrote:

Jordan Abel <ra*******@gmai l.com> writes:

On 2006-01-11, Artie Gold <ar*******@aust in.rr.com> wrote:

> #include "stdio.h"
...and this should be #include <stdio.h>
> #include "stdlib.h"
#include <stdlib.h>

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.

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

[Old Wolf]

Artie Gold wrote:

sunway wrote:

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.

[Keith Thompson]

"Old Wolf" <ol*****@inspir e.net.nz> writes:

Artie Gold wrote:

sunway wrote:

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

--
Keith Thompson (The_Other_Keit h) 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.