why the usage of gets() is dangerous.

[jayapal]

Hi all,

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

regards,
jayapal.

 

[John Gordon]

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

gets() does not allow you limit the amount of input, which means it
can potentially overflow the buffer into which the input is placed.

 

[jayapal]

gets() does not allow you limit the amount of input, which means it
can potentially overflow the buffer into which the input is placed.

Can u explain the differences b/w the scanf() and gets() ..?

Thanks,
Jayapal

 

[Ben Bacarisse]

Can u explain the differences b/w the scanf() and gets() ..?

Presumably you mean for string input? Using 'scanf("%[^\n]", buf)'
has the same problem as 'gets'. But scanf can be saved (just about)
since it permits a bounded input operation:

char buf[100];
...
if (scanf("%99[^\n]", buf) == 1) ...

 

[CBFalconer]

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

Because it cannot be used safely. There is no length control. Two
possible replacements for it are fgets() (a C standard function)
and ggets() (a non-standard function). ggets is available in
source form, with no restrictions, as ggets.zip at:

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

 

[jacob navia]

Hi all,

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

regards,
jayapal.

That function is deprecated and will disappear shortly.
Its usage is not recommended because there is no way to
limit the input that it will receive, and it can overflow
the input buffer.

 

[Flash Gordon]

jayapal wrote, On 16/11/07 17:18:

Can u explain the differences b/w the scanf() and gets() ..?

Please don't use contractions like "u" for "you" or "b/w" for "between".
They make it far harder to read your posts. For example, a lot of people
will be more likely to read "b/w" as "black and white" then "between"
and then have to work out what you actually meant.

As to your question, it is almost easier to say what the similarities
are. The main similarity is that they both get input from stdin, after
that they are very different. gets just keep reading input in to the
memory you provide a pointer to until either a newline is encountered or
your program crashes. scanf reads input as specified by the format
specifier you provide. With work, scanf *can* be used safely (although
it is not easy for a novice) but it is virtually impossible to use gets
safely and it definitely cannot be used safely for user input.

I would recommend you learn to use fgets and getc and build your input
routines using these function and separate passing. You can use sscanf
for the passing if you like, although you have to be careful, since it
is not as hard to use sscanf correctly as it is to use scanf or fscanf
correctly.

 

[CJ]

That function is deprecated and will disappear shortly.
Its usage is not recommended because there is no way to
limit the input that it will receive, and it can overflow
the input buffer.

This sort of absolute prohibition on gets() is completely wrong-headed.
It's completely fine to use gets(), as long as you use it properly. To
use it properly, *you* need to be in control of the data that gets()
reads. For throwaway utility routines this will often be the case, and
there's no problem using gets() in this case.

 

[dj3vande]

This sort of absolute prohibition on gets() is completely wrong-headed.
It's completely fine to use gets(), as long as you use it properly. To
use it properly, *you* need to be in control of the data that gets()
reads. For throwaway utility routines this will often be the case, and
there's no problem using gets() in this case.

Except that throwaway code has an annoying habit of not getting thrown
away. If you make a habit of using gets in your throwaway code, sooner
or later it WILL escape into the wild, and once that happens it's only
a matter of time before it becomes an exploitable bug.


dave

 

[Richard Heathfield]

CJ said:

This sort of absolute prohibition on gets() is completely wrong-headed.

No, it isn't. (Even a stopped clock is right twice a day.) There is never a
good reason to use the gets function.

It's completely fine to use gets(), as long as you use it properly.

To use it properly, precede it with an 'f', and modify the syntax of the
call accordingly.

To
use it properly, *you* need to be in control of the data that gets()
reads. For throwaway utility routines this will often be the case, and
there's no problem using gets() in this case.

That would be fine, if it were not for the facts that (a) you're not
necessarily as much in control of the data as you think you are, and (b)
throwaway routines have a bad habit of not being thrown away.

 

[karthikbalaguru]

Hi all,

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

gets is very very dangerous. Handle with care
It has buffer related worries.(Expects newline in its pocket to
work without causing any harm !)

Karthik Balaguru

 

[user923005]

Hi all,

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

For the same reason that failure to read the C-FAQ is dangerous.
Because you will look like a nincompoop due to the omission of common
sense.

12.23: Why does everyone say not to use gets()?

A: Unlike fgets(), gets() cannot be told the size of the buffer
it's to read into, so it cannot be prevented from overflowing
that buffer. As a general rule, always use fgets(). See
question 7.1 for a code fragment illustrating the replacement
of
gets() with fgets().

References: Rationale Sec. 4.9.7.2; H&S Sec. 15.7 p. 356.

 

[Paul Hsieh]

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

No set of program control can prevent gets() from having undefined
behavior. In fact, basically all C compilers implement gets() to have
undefined behavior. Because of this, the function has been slated to
be deprecated in the next C standard. I have made a safe
implementation of gets() that you can find as the first example here:

http://www.pobox.com/~qed/userInput.html

Please feel free to use it in lieu of the upcoming standard which will
make its usage obsolete.

 

[Eric Sosman]

Paul Hsieh wrote On 11/16/07 14:43,:

No set of program control can prevent gets() from having undefined
behavior. In fact, basically all C compilers implement gets() to have
undefined behavior. Because of this, the function has been slated to
be deprecated in the next C standard. I have made a safe
implementation of gets() that you can find as the first example here:

http://www.pobox.com/~qed/userInput.html

Please feel free to use it in lieu of the upcoming standard which will
make its usage obsolete.

Isn't there a buffer overrun vulnerability in the
fgetstralloc() function? Look carefully at the second
argument of the first call to getInputFrag().

 

[jameskuyper]

This sort of absolute prohibition on gets() is completely wrong-headed.
It's completely fine to use gets(), as long as you use it properly. To
use it properly, *you* need to be in control of the data that gets()
reads.

Keep in mind, of course, that there's absolutely nothing you can do
within strictly conforming C code that would give you the kind of
control you need to have to use gets() safely. The safety of such
usage depends upon something outside the C standard, and more likely
than not, something outside of the program itself.

It's trivial to replace any call to gets() with a similar call to
fgets() with minor modifications to the surrounding code, and that
change is sufficient to completely avoid the buffer overruns. I don't
know of any legitimate reason for not doing so.

 

[Ben Pfaff]

That function is deprecated and will disappear shortly.

It is not listed in the current C standard as deprecated.

 

[CJ]

Keep in mind, of course, that there's absolutely nothing you can do
within strictly conforming C code that would give you the kind of
control you need to have to use gets() safely. The safety of such
usage depends upon something outside the C standard, and more likely
than not, something outside of the program itself.

It's trivial to replace any call to gets() with a similar call to
fgets() with minor modifications to the surrounding code, and that
change is sufficient to completely avoid the buffer overruns. I don't
know of any legitimate reason for not doing so.

It's much more typing!

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

It is not listed in the current C standard as deprecated.

http://open-std.org/JTC1/SC22/WG14/www/docs/dr_332.htm

The status from the summary page is "closed, published in TC 3", and you
can find the added paragraph in n1256. Admittedly, I'm not sure if TC 3
is official just yet.

However, of course being deprecated does not mean it will actually be
removed any time soon.

 

[Paul Hsieh]

Paul Hsieh wrote On 11/16/07 14:43,:


Isn't there a buffer overrun vulnerability in the
fgetstralloc() function? Look carefully at the second
argument of the first call to getInputFrag().

Its 64. getInputFrag(*,64,*,*,*) never writes to more than 64 chars
(the extra '\0' only comes when the input is <= 64 in length; unlike
strncat, this is ok because the length read is always explicitly
returned), and the buffer passed (char blk[64]) in is 64 chars in
length. So ... what am I missing?

 

[Keith Thompson]

That function is deprecated and will disappear shortly.
Its usage is not recommended because there is no way to
limit the input that it will receive, and it can overflow
the input buffer.

It's true that gets() has been declared obsolescent and deprecated.
This is reflected in TC3 and in the latest standard draft, n1256.pdf.
This just happened within the last couple of months.

But please don't make the mistake of thinking that it "will disappear
shortly". It has not been removed from the C99 standard. In fact, any
conforming C99 implementation *must* provide gets(), undefined behavior
and all (though any implementation is free to warn about it).

Deprecation means that it will most likely be removed from the *next* C
standard, which is still a number of years away. Consider that the C99
standard is 8 years old, and still has not been fully implemented by the
vast majority of compilers. It will likely be decades, if ever, before
a significant number of implementations conform to a new C20YZ standard.
And even then, compilers will be free to continue to provide it in a
non-conforming mode, perhaps for backward compatibility.

I'm afraid that gets() is going to be around for a very long time. It's
still up to each of us, as programmers, to avoid using it.

jacob, if you really thing gets() will "disappear shortly", I'd be
interested in your reasoning.