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.

[Malcolm McLean]

"Paul Hsieh" <we******@gmail .comwrote in message

On Nov 16, 9:04 am, jayapal <jayapal...@gma il.comwrote:

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

Undefined behaviour means "undefined by the standard". It is possible,
though rather difficult, to implement a safe gets(), that is to say one that
always terminates the program with an error message if the buffer is
exceeded.

What is not possible to is implement is a safe fgets(), that is to say, one
that can be used safely given the limitations of the average human
programmer.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

Paul Hsieh wrote On 11/16/07 16:53,:

On Nov 16, 12:20 pm, Eric Sosman <Eric.Sos...@su n.comwrote:

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

>>>On Nov 16, 9:04 am, jayapal <jayapal...@gma il.comwrote:

>>>>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
implementati on 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().

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?

Nothing, I guess. I must have been confused by the
convoluted style. (Well, if it confuses me then it *must*
be convoluted, right?)

Still seems an awfully arcane way to skip and count
characters, though.

--
Er*********@sun .com

[Richard Heathfield]

Malcolm McLean said:

<snip>

It is possible,
though rather difficult, to implement a safe gets(), that is to say one
that always terminates the program with an error message if the buffer is
exceeded.

Show me.

What is not possible to is implement is a safe fgets(), that is to say,
one that can be used safely given the limitations of the average human
programmer.

The fgets function is very easy to use safely.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[dj3vande]

In article <sl************ *******@nospam. com>, CJ <no****@nospam. comwrote:

>On 16 Nov 2007 at 20:47, ja*********@ver izon.net wrote:

>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!

If that's what you're worried about, why aren't you using Perl?
dave

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.in validwrote in message

>It is possible,
though rather difficult, to implement a safe gets(), that is to say one
that always terminates the program with an error message if the buffer is
exceeded.

Show me.

We'll declare that pointer cosist of three values - the address, the start
of the object, and the end of the object.
Now in the write to array code we specify that if the address execceds the
end of the object, the program is to terminate with an error meaage.

With this device we have a perfectly safe gets() fucntion. It cannot return
an incorrect string, or corrupt another variable, or put little elves on
screen. It can only fill the buffer correctly or report that it has been
exceeded.

>

>What is not possible to is implement is a safe fgets(), that is to say,
one that can be used safely given the limitations of the average human
programmer.

The fgets function is very easy to use safely.

Time after time it has been shown that this is not the case. Very often
people treat incomplete reads as full lines. So if the line contains a drug
dose your fgets() - enabled machine might deliver only one tenth of the
amount needed, given an off by one line length error.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

>
"Richard Heathfield" <rj*@see.sig.in validwrote in message

>>It is possible,
though rather difficult, to implement a safe gets(), that is to say one
that always terminates the program with an error message if the buffer
is exceeded.

Show me.

We'll declare that pointer cosist of three values - the address, the
start of the object, and the end of the object.

I look forward to your reference implementation.

<snip>

>>What is not possible to is implement is a safe fgets(), that is to say,
one that can be used safely given the limitations of the average human
programmer.

The fgets function is very easy to use safely.

Time after time it has been shown that this is not the case.

You can misuse *anything* if you try hard enough. You have to try
reasonably hard to misuse fgets, whereas to misuse gets you only need call
it.

Very often
people treat incomplete reads as full lines.

Very often people drive at 40 in a 30. That does not mean it is difficult
to drive at 30.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

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

On Fri, 16 Nov 2007 23:19:12 +0000, Malcolm McLean wrote:

"Richard Heathfield" <rj*@see.sig.in validwrote in message

>>It is possible,
though rather difficult, to implement a safe gets(), that is to say
one that always terminates the program with an error message if the
buffer is exceeded.

Show me.

We'll declare that pointer cosist of three values - the address, the
start of the object, and the end of the object.

So, in

struct S {
char c[10];
int i;
} s;

does a pointer to s.c store the end as &s.c[10]? Or does it store the end
as &s + 1? If the former, there are cases where it's simply not clear at
all where the buffer ends. If the latter, it doesn't prevent writing past
the end of the buffer.

I do agree that bounded pointers would be useful, but C being what it is,
I don't believe it's possible to make it completely safe.

[Malcolm McLean]

"Harald van Dijk" <tr*****@gmail. comwrote in message

On Fri, 16 Nov 2007 23:19:12 +0000, Malcolm McLean wrote:

>"Richard Heathfield" <rj*@see.sig.in validwrote in message

>>>It is possible,
though rather difficult, to implement a safe gets(), that is to say
one that always terminates the program with an error message if the
buffer is exceeded.

Show me.

We'll declare that pointer cosist of three values - the address, the
start of the object, and the end of the object.

So, in

struct S {
char c[10];
int i;
} s;

does a pointer to s.c store the end as &s.c[10]? Or does it store the end
as &s + 1? If the former, there are cases where it's simply not clear at
all where the buffer ends. If the latter, it doesn't prevent writing past
the end of the buffer.

A pointer to s.c would have to store the end as &s.c[10].
It is illegal to convert from a struct S * to a char *, except in the niggly
case of a char or char array being the first member, in which case it must
have the same address as the whole struct. So the compiler does in fact have
to be very clever.

however char *ptr = (char *) (void *) &s;

is I think still illegal. So you cannot defeat the system with a intricate
list of void * intermediates.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

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

On Sat, 17 Nov 2007 00:28:43 +0000, Malcolm McLean wrote:

"Harald van Dijk" <tr*****@gmail. comwrote in message

>On Fri, 16 Nov 2007 23:19:12 +0000, Malcolm McLean wrote:

>>"Richard Heathfield" <rj*@see.sig.in validwrote in message
It is possible,
though rather difficult, to implement a safe gets(), that is to say
one that always terminates the program with an error message if the
buffer is exceeded.

Show me.

We'll declare that pointer cosist of three values - the address, the
start of the object, and the end of the object.

So, in

struct S {
char c[10];
int i;
} s;

does a pointer to s.c store the end as &s.c[10]? Or does it store the
end as &s + 1? If the former, there are cases where it's simply not
clear at all where the buffer ends. If the latter, it doesn't prevent
writing past the end of the buffer.

A pointer to s.c would have to store the end as &s.c[10].

Okay, so then you can't get back the original &s?

struct S {
char c[10];
int i;
} s[2];

char *p = &s[1].c[0];

The range for p would be &s[1].c[0] through &s[1].c[10], but I don't
believe there's anything non-standard about casting p to struct S *, and
subtracting 1. (With a stricter reading of the standard, you might need
to cast p to char(*)[10], and only then to struct S, but this doesn't
change anything important.)

It is illegal
to convert from a struct S * to a char *,

It's allowed for two reasons here. Firstly, *any* object can be addressed
as an array of char. Given int i, ((char *) &i) through (char *) &i +
sizeof i are all valid pointers. Given struct S s, (char *) &s + sizeof s
are all valid pointers. The second reason you mention below.

except in the niggly case of a
char or char array being the first member, in which case it must have
the same address as the whole struct. So the compiler does in fact have
to be very clever.

It has to be able to construct data that is no longer available.

however char *ptr = (char *) (void *) &s;

is I think still illegal. So you cannot defeat the system with a
intricate list of void * intermediates.

Well, this specific example is legal, but I think I get the point you're
making here, and I agreed already that bounded pointers, even while not
perfect, are useful.

[Keith Thompson]

jacob navia wrote:

Keith Thompson wrote:

[...]

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

Nothing, just hopes that now that is deprecated, people will
stop using it, and it will disappear in a few years.

Alas, hoping won't make it happen. As I said, any implementation that
claims to conform to any C standard, up to and including C99, *must*
provide gets().

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"