char* gets(char* buffer)

[Sathyaish]

I noticed that gets() reads into the buffer even if the you've not
allocated enough memory. For instance, if you do:

char *str=(char*)malloc(sizeof(char));
printf("Enter something about yourself below:\n\n");
gets(str);
printf("\n\n");
puts(str);

This works without a problem even though I initialized the buffer with
a single char only for the heck of it. Of course, not initializing the
char pointer at all will definitely result in a crash. For instance,
doing just this definitely would result in a null-pointer exception
and would crash the program.

char *str
printf("Enter something about yourself below:\n\n");
gets(str);
printf("\n\n");
puts(str);

So, my question is whether with gets(), unlike most other C functions
where we the programmers are supposed to make good guesses as to the
amount of memory we need, can we just get away without caring about
the length of the buffer required?

If I explicity say,

char str[1000];
printf("Enter something about yourself below:\n\n");
gets(str);
printf("\n\n");
puts(str);

I explcitiy define the length of the buffer I would be using, but
gets() keeps returning input even if it exceeds the 999 characters I
expected.

The documentation here

http://www.cplusplus.com/ref/cstdio/gets.html

says:

There is no limit on how many characters gets may read, so it's your
job to determinate the length of the buffer you will need.

Please shed some light on this function's behaviour as regards buffer
allocation.

 

[Dave Vandervies]

I noticed that gets() reads into the buffer even if the you've not
allocated enough memory. For instance, if you do:
[snip]

Please shed some light on this function's behaviour as regards buffer
allocation.

There's no way to avoid overwriting memory if the input is longer than
you expect. This means that it's impossible to use gets without creating
a bug that allows a buffer overrun.
The solution is to Don't Do That. Use something like
fgets(buf,sizeof buf,stdin)
instead if longer-than-expected input is an error (if the string you
get back doesn't include a '\n', either you have an input error or the
buffer is full and the rest of the line is still waiting in the input),
or google for ggets in posts here if input needs to be arbitrarily sized.


dave

 

[Mabden]

I noticed that gets() reads into the buffer even if the you've not
allocated enough memory. For instance, if you do:
[snip]

Please shed some light on this function's behaviour as regards buffer
allocation.

There's no way to avoid overwriting memory if the input is longer than
you expect. This means that it's impossible to use gets without creating
a bug that allows a buffer overrun.
The solution is to Don't Do That. Use something like
fgets(buf,sizeof buf,stdin)
instead if longer-than-expected input is an error (if the string you
get back doesn't include a '\n', either you have an input error or the
buffer is full and the rest of the line is still waiting in the input),
or google for ggets in posts here if input needs to be arbitrarily sized.

I don't really see the need for a gets() or fgets(). It's just a loop to
do getc() for you, so why not just do it yourself and _know_ what is
going on. I'm generally looking for more than just the newline char when
I'm parsing data so I just read a char at a time. I mean, aren't you
going to go through the string (or line) you just inputted anyway?
What's the point of parsing it twice?

 

[Default User]

Sathyaish wrote:

So, my question is whether with gets(), unlike most other C functions
where we the programmers are supposed to make good guesses as to the
amount of memory we need, can we just get away without caring about
the length of the buffer required?

No.


http://www.eskimo.com/~scs/C-faq/q12.23.html




Brian Rodenborn

 

[Keith Thompson]

I noticed that gets() reads into the buffer even if the you've not
allocated enough memory.

Which invokes undefined behavior, which (if you're unlucky) can
manifest itself as your program not exhibiting any visible problems.

Never use gets().

This is question 12.23 of the C FAQ,
<http://www.eskimo.com/~scs/C-faq/top.html>.

 

[Eric Sosman]

I noticed that gets() reads into the buffer even if the you've not
allocated enough memory. For instance, if you do:
[snip]


Please shed some light on this function's behaviour as regards buffer
allocation.

There's no way to avoid overwriting memory if the input is longer than
you expect. This means that it's impossible to use gets without
creating

a bug that allows a buffer overrun.
The solution is to Don't Do That. Use something like
fgets(buf,sizeof buf,stdin)
instead if longer-than-expected input is an error (if the string you
get back doesn't include a '\n', either you have an input error or the
buffer is full and the rest of the line is still waiting in the
input),

or google for ggets in posts here if input needs to be arbitrarily

sized.


I don't really see the need for a gets() or fgets(). It's just a loop to
do getc() for you, so why not just do it yourself and _know_ what is
going on. I'm generally looking for more than just the newline char when
I'm parsing data so I just read a char at a time. I mean, aren't you
going to go through the string (or line) you just inputted anyway?
What's the point of parsing it twice?

Convenience. getc() gives you only one character of
look-ahead (because you can have only one ungetc()'d char
outstanding), so if you need more you'll need to manage
some kind of buffer anyhow.

Convenience. Once you've found a sequence of interesting
input characters you may want to do something with them, and
many of the "somethings" involve calling C library functions
like strcmp() or strtod() or even sscanf(), all of which
need to see the entire string at once.

Convenience is certainly not the be-all and end-all of
programming, but there's much to be said for it. Who among
us has not used the convenient printf(...) instead of the
equivalent but clumsier fprintf(stdout,...)? Who has not
used printf() when puts() would have done the job?

There are plenty of situations where character-by-character
input is preferable: You can handle Really Long Lines without
requiring Really Big Buffers, you can change your mind in
mid-stream before reading too far ahead (scanf() couldn't
be implemented atop fgets(), for example), and so on. But
in situations where these aren't of great concern, fgets()
is simply ... convenient.

(By the way, I'm not suggesting that fgets() is perfect.
Its return value is particularly annoying, as it tells you
something you already knew instead of something you didn't,
something that fgets() has figured out that you may need to
figure out all over again. fgets() is blemished -- but so
are we all, says my theology professor.)

 

[Mike Wahler]

I noticed that gets() reads into the buffer even if the you've not
allocated enough memory. For instance, if you do:
[snip]

Please shed some light on this function's behaviour as regards buffer
allocation.

There's no way to avoid overwriting memory if the input is longer than
you expect. This means that it's impossible to use gets without creating
a bug that allows a buffer overrun.
The solution is to Don't Do That. Use something like
fgets(buf,sizeof buf,stdin)
instead if longer-than-expected input is an error (if the string you
get back doesn't include a '\n', either you have an input error or the
buffer is full and the rest of the line is still waiting in the input),
or google for ggets in posts here if input needs to be arbitrarily sized.

I don't really see the need for a gets() or fgets(). It's just a loop to
do getc() for you,

'gets()' and 'fgets()' might be implemented by invoking
'getc()', but AFAIK, they're not required to. They might
call 'lower level' OS functions directly (which would
typically have better performance than 'getc()', if only
because one level of abstraction is eliminated). As long as
the *behavior* conforms to the standard, the implementation
is left to the implementor.

-Mike

 

[Xenos]

I don't really see the need for a gets() or fgets(). It's just a loop to
do getc() for you, so why not just do it yourself and _know_ what is
going on. I'm generally looking for more than just the newline char when
I'm parsing data so I just read a char at a time. I mean, aren't you
going to go through the string (or line) you just inputted anyway?
What's the point of parsing it twice?

Because sometimes you want to decouple the input retrieval from the parser.

 

[Sathyaish]

Thanks, Dave.

I noticed that gets() reads into the buffer even if the you've not
allocated enough memory. For instance, if you do:
[snip]

Please shed some light on this function's behaviour as regards buffer
allocation.

There's no way to avoid overwriting memory if the input is longer than
you expect. This means that it's impossible to use gets without creating
a bug that allows a buffer overrun.
The solution is to Don't Do That. Use something like
fgets(buf,sizeof buf,stdin)
instead if longer-than-expected input is an error (if the string you
get back doesn't include a '\n', either you have an input error or the
buffer is full and the rest of the line is still waiting in the input),
or google for ggets in posts here if input needs to be arbitrarily sized.


dave

 

[CBFalconer]

I noticed that gets() reads into the buffer even if the you've
not allocated enough memory. For instance, if you do:
[snip]

Please shed some light on this function's behaviour as regards
buffer allocation.

There's no way to avoid overwriting memory if the input is longer
than you expect. This means that it's impossible to use gets
without creating a bug that allows a buffer overrun.
The solution is to Don't Do That. Use something like
fgets(buf,sizeof buf,stdin)
instead if longer-than-expected input is an error (if the string
you get back doesn't include a '\n', either you have an input
error or the buffer is full and the rest of the line is still
waiting in the input), or google for ggets in posts here if
input needs to be arbitrarily sized.

ggets is available at:

<http://cbfalconer.home.att.net/download/ggets.zip>