Why is it dangerous?

[Julian]

'evening.

I'm not new to C and have been programming in it since I was 8 but
here's a strange problem I've never seen before.

When I compile a program from our C course with a windows compiler
there is no problem but when I try to compile it with a linux compiler
it complains that

a_03.c:(.text+0 x4d): warning: the `gets' function is dangerous
and should not be used.

Is linux more dangerous than windows? Where can I download a
non dangerous gets function? I have never used gets before is
there undefined behavior somewhere?
Here is a trimmed down example program from my assignment that
demonstrates the problem

#include <stdio.h>
#include <malloc.h>

void main()
{
char *string;
printf("enter string (max 2000 chars): ");
fflush(stdin);
fflush(stdout);
string = (char *)malloc(2001);
if(!string) exit(1);
gets(string);
printf("you entered: %s\n", string);
free(string);
exit(0);
}

On windows with TurboC and Lcc no error is printed. On linux with
gcc it says gets is dangerous.

Please advise my instructor says gcc is overly pedantic.

[Antoninus Twink]

On 11 Aug 2008 at 22:17, Richard Heathfield wrote:

Willem said:

>The person driviong that other car would, if you were killed, have the
very traumatic experience of having caused your death, as opposed to just
causing you some injuries had you worn your seatbelt.

They might also suffer the even more traumatic experience of having you
smash through their windscreen, injuring or even killing them.

Oh come on, has this ever actually happened? It's no surprise that you
take the authoritarian view on this, but don't invent facts to support
your "case".

>So by choosing not to wear your seatbelt you put others in danger of
being traumatized by your death.

And possibly their own.

Pure hyperbolic melodrama!

[CBFalconer]

James Dow Allen wrote:

>

.... snip about gets ...

>
Whenever I build the Index to the Fabulous Pedigree
http://fabpedigree.com/altix.htm
I do several hundred thousand gets()'s, but none of them are
"dangerous" . I live with a few "dangerous" messages during the
build (although I'm sure the pedants would prefer that each of
the several hundred thousand gets()'s produced its own such
message. :-)

They're all dangerous. For example, a one bit error in reading a
'\n' from your prewritten data can blow everything.

I assume you use it because of the simplicity of the call. You can
get that simplicity, together with safety, by using ggets. All you
have to do is free the returned string when you are done with it.
It is available, written in standard C, and put in the public
domain, at:

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

EX:
char *line;
...
while (0 == ggets(&line)) {
/* use the line */
free(line);
}

or you can keep the returned line as long as you need it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Ben Bacarisse]

CBFalconer <cb********@yah oo.comwrites:

James Dow Allen wrote:

>>

... snip about gets ...

>>
Whenever I build the Index to the Fabulous Pedigree
http://fabpedigree.com/altix.htm
I do several hundred thousand gets()'s, but none of them are
"dangerous" . I live with a few "dangerous" messages during the
build (although I'm sure the pedants would prefer that each of
the several hundred thousand gets()'s produced its own such
message. :-)

They're all dangerous. For example, a one bit error in reading a
'\n' from your prewritten data can blow everything.

I assume you use it because of the simplicity of the call. You can
get that simplicity, together with safety, by using ggets.

How does ggets overcome the problem you've just identified with the
OP's use of gets?

--
Ben.

[fjblurt]

On Aug 11, 12:25 pm, [e-mail] rditt.org (Gordon Burditt) wrote:

The way to get rid of the warning on gets(), if you really want to
do it, is (on FreeBSD, anyway, but I suspect it applies to other
systems that use gcc as a default compiler):

(1) Remove the call to __warn_referenc es() in gets.c .
(2) Rebuild the C library.

Rebuilding the compiler isn't necessary.

You can also

objcopy -R .gnu.warning.ge ts /usr/lib/libc.a

Repeat for libc.so, etc.

It's a little surprising that 'ld' doesn't appear to have an option to
suppress these.

[Andrew Poelstra]

On 2008-08-12, Ben Bacarisse <be********@bsb .me.ukwrote:

CBFalconer <cb********@yah oo.comwrites:

>>
I assume you use it because of the simplicity of the call. You can
get that simplicity, together with safety, by using ggets.

How does ggets overcome the problem you've just identified with the
OP's use of gets?

ggets() interally allocates a dynamically-resized buffer. In the case
that it runs out of memory, it returns an appropriate error condition.

On the other hand, if you really do have "complete control" over your
input, it would be cheaper to use fgets(), since you can use a fixed-
size buffer and the sizeof operator.

The choice is one between convienence and raw efficiency. Neither one
equates to using gets().

--
Andrew Poelstra ap*******@wpsof tware.com
To email me, use the above email addresss with .com set to .net

[CBFalconer]

Ben Bacarisse wrote:

CBFalconer <cb********@yah oo.comwrites:

>James Dow Allen wrote:

>>>

... snip about gets ...

>>>
Whenever I build the Index to the Fabulous Pedigree
http://fabpedigree.com/altix.htm
I do several hundred thousand gets()'s, but none of them are
"dangerous" . I live with a few "dangerous" messages during the
build (although I'm sure the pedants would prefer that each of
the several hundred thousand gets()'s produced its own such
message. :-)

They're all dangerous. For example, a one bit error in reading a
'\n' from your prewritten data can blow everything.

I assume you use it because of the simplicity of the call. You
can get that simplicity, together with safety, by using ggets.

How does ggets overcome the problem you've just identified with
the OP's use of gets?

I suggest you download it and see for yourself. It is only about
an 11k download.

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Richard Heathfield]

Ben Bacarisse said:

CBFalconer <cb********@yah oo.comwrites:

>James Dow Allen wrote:

>>>

... snip about gets ...

>>>
Whenever I build the Index to the Fabulous Pedigree
http://fabpedigree.com/altix.htm
I do several hundred thousand gets()'s, but none of them are
"dangerous" . I live with a few "dangerous" messages during the
build (although I'm sure the pedants would prefer that each of
the several hundred thousand gets()'s produced its own such
message. :-)

They're all dangerous. For example, a one bit error in reading a
'\n' from your prewritten data can blow everything.

I assume you use it because of the simplicity of the call. You can
get that simplicity, together with safety, by using ggets.

How does ggets overcome the problem you've just identified with the
OP's use of gets?

It doesn't - insofar as it makes no special provision against one-bit
errors in reading a '\n' from your prewritten data. It does, however,
return an error if it runs out of memory. But it fails to take the obvious
precaution of allowing the caller to specify an upper limit to the number
of bytes taken from the stream.

So let's say you have this situation - you know your lines are no longer
than 6 bytes (the same argument applies to more typical line lengths, eg
72 or 80, but the much lower value is chosen simply because it is easy to
write and easy to read in a Usenet article).

Here are your data:

3.141
1.618

A one bit error in reading a '\n' from the 3.141 line results in it being
interpreted as a J instead (01001010 instead of 00001010). So if ggets
really did overcome this obstacle, it would detect the one-bit error and
correct for it or at least report it. In practice, what ggets will do is
read the next line too, so that you'll get:

3.141J1.618

which is very much *not* what is intended. Now, I'm not saying that ggets
*should* be able to defend against bit errors like this. I'm saying it
*doesn't*.

I have suggested, many times, that Mr Falconer should add a "maximum bytes
to read" parameter to ggets - and doing so would offer the caller a
reasonable line of defence against such an error: rc = ggets(&line, 6)
would give you a fighting chance of at least detecting that something is
wrong in the above situation. But ggets in its current state does not, so
the *best* you can hope for is that you run out of memory. Not a happy
state of affairs.

Again, I stress that there is no shame in an input routine not detecting
bit errors of this kind. But ggets was offered, by its author, as a
solution to the problem of a one bit error in reading a '\n' - and it is
no such thing.

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

[CBFalconer]

Richard Heathfield wrote:

>

.... snip ...

>
Again, I stress that there is no shame in an input routine not
detecting bit errors of this kind. But ggets was offered, by its
author, as a solution to the problem of a one bit error in
reading a '\n' - and it is no such thing.

No I didn't. It is a solution to having such an error blow up your
machine. Your long mischaracteriza tion is not helping anybody.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>>

... snip ...

>>
Again, I stress that there is no shame in an input routine not
detecting bit errors of this kind. But ggets was offered, by its
author, as a solution to the problem of a one bit error in
reading a '\n' - and it is no such thing.

No I didn't.

Then I am at a loss to explain your previous response.

It is a solution to having such an error blow up your machine.

Perhaps you could explain how such an error could blow up one's machine in
the first place.

Your long mischaracteriza tion is not helping anybody.

Well, obviously I don't agree that it's a mischaracteriza tion. Neither do I
agree that it is necessarily of no help to anybody. Perhaps you could
explain precisely why you think it is a mischaracteriza tion.

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

[vippstar]

On Aug 12, 9:43 am, Richard Heathfield <[e-mail].i nvalidwrote:
<snip>

It doesn't - insofar as it makes no special provision against one-bit
errors in reading a '\n' from your prewritten data. It does, however,
return an error if it runs out of memory. But it fails to take the obvious
precaution of allowing the caller to specify an upper limit to the number
of bytes taken from the stream.

So let's say you have this situation - you know your lines are no longer
than 6 bytes (the same argument applies to more typical line lengths, eg
72 or 80, but the much lower value is chosen simply because it is easy to
write and easy to read in a Usenet article).

Here are your data:

3.141
1.618

A one bit error in reading a '\n' from the 3.141 line results in it being
interpreted as a J instead (01001010 instead of 00001010). So if ggets
really did overcome this obstacle, it would detect the one-bit error and
correct for it or at least report it. In practice, what ggets will do is
read the next line too, so that you'll get:

<snip>

What is this one-bit error you are talking about? It's the first time
I hear it.
Assuming that error happends, wouldn't the error flag for the stream
be set?