Re: gets(); was: Re: Why does rewind() ignore errors?

Wojtek Lerch wrote:
"jacob navia" <jacob@xxxxxxxxxxxxxxxx> wrote in message
Costs of a line too long because of some program bug using gets():
1) Complete system failure, memory overwrite with
unforeseeable consequences.

In most environments these days, the chances that a random buffer overflow
may do any serious damage before the program dies from a segment violation
are small;

He said unforseen. Not random. The two words are different. Its the
difference between an anomoly and a directed attack.

[...] otherwise debugging C programs would be just too scary.

Because of the possibility of latent heap corruption, and the use of
multithreading in real environments, C is already a nightmare to debug.

[...] A decent
OS won't allow a program running as a regular user to cause a complete
system failure, even if it tries; the worst that can happen is that the
program overwrites some of your files, or kills some of your processes.

Huh? You are aware of an OS that provides you this as a *guarantee*?

[...] But
even that is extremely unlikely in practice. Unless, of course, the long
line was carefully prepared.

But, of course, if your program is intended to run in an environment without
memory protection, then yes, it's scary and you need to be careful.

Or if you simply demand that the program not crash at the drop of a
hat. Some programs, even those running at user level can be mission
critical sometimes.

[...] If
writing through a bad pointer can hang the OS, that's bad; if it can
accidentally hit the chip that controls the X-ray transmitter, that's
potentially much worse.

How about exposing a password?

2) Difficult debugging since you do not see the bug
immediately in most cases, but see the consequences, MUCH
later.

Some programs are intended to be run once and then thrown away; in those
cases, there's no such thing as much later.

So this is an argument about one set of cases versus another? I think
jacob's point is well made here. Buffer overflows most commonly don't
raise any immediate red flags.

Costs of using strcat_s:
1) Writing several dozen characters at each call and
a test for the strcat_s result.

I presume you meant gets_s?

2) The debugging costs are trivial since a clear error
message pinpoints the exact location of the bug.

But "the" bug is just one of many possible bugs; even if the line isn't too
long, it might still be wrong and cause undefined behaviour at some point
after it's been read. Fully validating the correctness of input is likely
to be more complicated than just changing gets to gets_s or fgets, and often
much more complicated and expensive than making sure that the other program
doesn't produce invalid output.

But those are not comparable. There is nothing you can do about the
gets() bug. As to other bugs, that's just a matter of the programmer
skill versus the complexity.

[...] Sometimes it's a good idea to do both;
sometimes it might be a pure waste of time. If I can easily prove that all
the lines are produced by calls to printf("%d,%d\n",x,y), then using gets()
to read them into an 80-byte buffer doesn't sound too unsafe to me.
(Personally, I'd still use fgets(), but that's because I tend to be more
pedantic than really necessary.)

Now, what you would choose?

Typically I use fgets().

And you typically waste time nailing trailiing '\n's and you are unable
to reliably read from a binary stream. And for some applications,
truncation is an error, so you have to do a lot more than just fgets()
anyways.

If you want to get rid of these headaches, you should use getInput from
here: http://www.pobox.com/~qed/userInput.html or just use the Better
String Library from here: http://bstring.sf.net/ to get rid of all
sorts of headaches.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages