newbie question, fread problem

[CBFalconer]

.... snip ...

How about this one:

#include <stdio.h>
int main(void)
{
int ch;
unsigned int count=0;
char buf[1024],*ptr=buf;

while ((ch=getchar())!='\n')
{
if (++count>=sizeof(buf))
break;
*ptr++=ch;
}
*ptr='\0';
printf("%s\n",buf);
return 0;
}

IMO it is clearer here to use indices and let the compiler optimize
to pointers if it so wishes. Write for clarity, not efficiency.
Use blanks! Always consider EOF.

#include <stdio.h>
int main(void)
{
int ch;
unsigned int count = 0;
char buf[1024];

while (('/n' != (ch = getchar())) && (EOF != ch)) {
if (count >= sizeof buf - 1) break;
buf[count++] = ch;
}
buf[count] = '\0';
printf("%s\n", buf);
return 0;
}

This still doesn't handle the flushing (or other treatment) of
overlong lines. This doesn't matter here because the program
exits, but would be of concern if this was part of an interactive
process.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[CBFalconer]

no, i meant gets(), get string from stdin

INCLUDE CONTEXT. Never, ever, use gets(). Not even under threat
of torture from Bush and Cheney. gets() causes more trouble than
wine, women, cars, and fatty foods combined. Women and cats are
more controllable than gets(). See fgets() and/or my ggets().

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Default User]

hi, all!
i think, better way is using gets() instead fread()
in this context(i.e. question), for output should be used
puts();

Please read my .sig below.



Brian

 

[Keith Thompson]

hi, all!
i think, better way is using gets() instead fread()
in this context(i.e. question), for output should be used
puts();

or i`m wrong?

Yes, you're wrong. Never use gets(). Never. Never ever.

<http://www.c-faq.com/stdio/getsvsfgets.html>

 

[stathis gotsis]

... snip ...

How about this one:

#include <stdio.h>
int main(void)
{
int ch;
unsigned int count=0;
char buf[1024],*ptr=buf;

while ((ch=getchar())!='\n')
{
if (++count>=sizeof(buf))
break;
*ptr++=ch;
}
*ptr='\0';
printf("%s\n",buf);
return 0;
}

IMO it is clearer here to use indices and let the compiler optimize
to pointers if it so wishes. Write for clarity, not efficiency.
Use blanks! Always consider EOF.

Thank you for the corrections, we should consider EOF for the following
reasons:
1) Stdin can be redirected to a file
2) CTRL-Z (or CTRL-D) produce EOF.
Are there any other reasons?

Offtopic: Is CTRL-Z equivalent to EOF on a windows console? Even when
considering EOF, i got some strange results when pressing that key
combination.

#include <stdio.h>
int main(void)
{
int ch;
unsigned int count = 0;
char buf[1024];

while (('/n' != (ch = getchar())) && (EOF != ch)) {
'\n'?

if (count >= sizeof buf - 1) break;
buf[count++] = ch;
}
buf[count] = '\0';
printf("%s\n", buf);
return 0;
}

This still doesn't handle the flushing (or other treatment) of
overlong lines. This doesn't matter here because the program
exits, but would be of concern if this was part of an interactive
process.

Could this be handled in a portable way maybe?

 

[Keith Thompson]

ok, i promise be carefuly in future
at last present for comunity last, more security solution:

#include <stdio.h>

int main(int argc, char * argv[]){
int ch, cnt;
char buff[1024], * ptr = buff;

for(cnt = 0;(ch = getchar()) != 10 && cnt < 1024; cnt++){
*(ptr++) = ch;
}
* ptr = '\0';
printf("%s\n", buff);
return 0;
}

Please read and understand <http://cfaj.freeshell.org/google/>
*before* you post here again.

What is the significance of the value 10? I presume you mean '\n',
but it's not guaranteed to have the value 10; it's guaranteed to have
the value '\n'.

What happens if getchar() returns EOF before you reach the end of the
line?

Avoid magic numbers. If you decided to change the size of your buffer
to something other than 1024, are you *certain* that you'd also
remember to change the value 1024 in your for loop? Are you equally
certain that you wouldn't also change some other unrelated 1024 in
your program?

Why are you re-implementing the fgets() function rather than just
calling it?

 

[CBFalconer]

... snip ...

How about this one:

#include <stdio.h>
int main(void)
{
int ch;
unsigned int count=0;
char buf[1024],*ptr=buf;

while ((ch=getchar())!='\n')
{
if (++count>=sizeof(buf))
break;
*ptr++=ch;
}
*ptr='\0';
printf("%s\n",buf);
return 0;
}

IMO it is clearer here to use indices and let the compiler optimize
to pointers if it so wishes. Write for clarity, not efficiency.
Use blanks! Always consider EOF.

Thank you for the corrections, we should consider EOF for the
following reasons:
1) Stdin can be redirected to a file
2) CTRL-Z (or CTRL-D) produce EOF.
Are there any other reasons?

Offtopic: Is CTRL-Z equivalent to EOF on a windows console? Even
when considering EOF, i got some strange results when pressing
that key combination.

It normally signals EOF only at the beginning of a line. But no
guarantees.

#include <stdio.h>
int main(void)
{
int ch;
unsigned int count = 0;
char buf[1024];

while (('/n' != (ch = getchar())) && (EOF != ch)) {

'\n'?

yup - good catch.

if (count >= sizeof buf - 1) break;
buf[count++] = ch;
}
buf[count] = '\0';
printf("%s\n", buf);
return 0;
}

This still doesn't handle the flushing (or other treatment) of
overlong lines. This doesn't matter here because the program
exits, but would be of concern if this was part of an interactive
process.

Could this be handled in a portable way maybe?

I normally keep the following function around. Note that the
caller can tell if EOF was encountered.

int flushln(FILE *f) {
int ch;

do {
ch = getc(f);
while (('\n' != ch) && (EOF != ch));
return ch;
}

Using this requires that you know a-priori whether or not an
earlier line has been completely absorbed. If parsing routines
leave the terminal char in the input stream, this is handled
automatically. fgets is an especially nuisance for this, although
you can tell what happened. fscanf and scanf normally behave this
way, but have other problems for interactive use.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[stathis gotsis]

It normally signals EOF only at the beginning of a line. But no
guarantees.

Yes, EOF (CTRL-Z) at the beginning of the line can be handled. However, if i
type CTRL-Z somewhere in the middle of the line, everything gets messed up.
The getchar() function will not return EOF, actually stops reading just
before EOF, blocks there and waits for another line of input. I find that
strange.

I normally keep the following function around. Note that the
caller can tell if EOF was encountered.

int flushln(FILE *f) {
int ch;

do {
ch = getc(f);
while (('\n' != ch) && (EOF != ch));
return ch;
}

Using this requires that you know a-priori whether or not an
earlier line has been completely absorbed. If parsing routines
leave the terminal char in the input stream, this is handled
automatically. fgets is an especially nuisance for this, although
you can tell what happened. fscanf and scanf normally behave this
way, but have other problems for interactive use.

If i got this right, flushln() absorbs long lines which may cause buffer
overflow, but we have to know in advance if the next line to be read is
long.

 

[zhousqy]

use "fgets" instead of "gets", like "fgets(array, sizeof(array), stdin)"

 

[CBFalconer]

.... snip ...

If i got this right, flushln() absorbs long lines which may cause
buffer overflow, but we have to know in advance if the next line
to be read is long.

No, it absorbs the tail of any line, if it exists. If the tail has
already been absorbed it absorbs the next line. Just read the
code.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[stathis gotsis]

No, it absorbs the tail of any line, if it exists. If the tail has
already been absorbed it absorbs the next line. Just read the
code.

I got it now, thank you.