gets() rationale

wv****@yahoo.com (Will) writes:

and maybe strcpy() should go too since it does not (cannot) check how much
it can copy? Long live to memcpy()!

The program has complete control over the arguments it passes to
strcpy(). Most programs have no direct control over what's sent to
them on stdin.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Nov 14 '05 #16

Will

If u suggest calling strlen() before calling strcpy() *EVERY TIME*, u
are suggesting yet another problem. It's so easy to blow strlen().

Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<br**********@oravannahka.helsinki.fi>...

Will <wv****@yahoo.com> scribbled the following:
and maybe strcpy() should go too since it does not (cannot) check how much
it can copy? Long live to memcpy()!

Umm... have you heard of strlen()?

Nov 14 '05 #17

Arthur J. O'Dwyer

On Thu, 10 Dec 2003, Will wrote:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote...
Will <wv****@yahoo.com> scribbled the following:
and maybe strcpy() should go too since it does not (cannot)
check how much it can copy? Long live to memcpy()!
Umm... have you heard of strlen()?

If u suggest calling strlen() before calling strcpy() *EVERY TIME*, u
are suggesting yet another problem. It's so easy to blow strlen().

Because it's annoying as hell.
Why not?
Please don't top-post.
Joona's point (or at least the point I would have made if I were
Joona) was that

char *p = "foo";
char q[4];
strcpy(q, p);

is *perfectly* correct, while anything along the lines of

char p[100000];
gets(p);

is *broken by design*. There's simply no possible comparison between
gets() and strcpy() as far as correctness goes.
Your response made it sound as if you thought strcpy() could possibly
copy an arbitrarily large number of characters without the programmer's
knowing about it. So (I assume) Joona mentioned the strlen() function,
which is a portable and safe way of finding out exactly *how many*
characters strcpy() is going to be copying at any time. If you can't
keep track of the length of some string yourself, strlen() is always
available.

Oh, and of course it's impossible to "blow" strlen(), unless you
suggest passing NULL or some other non-string pointer to it. Sure,
you can crash your program with

int p;
strlen((void*)&p);

any time you like. But that's just silly; I don't think you could
have been referring to that. Which leads me to the conclusion that
you were confused when you wrote
It's so easy to blow strlen().

HTH,
-Arthur

--
U is not a word. It is a letter.

Nov 14 '05 #18

Will wrote: *** top posting fixed ***

Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message
Will <wv****@yahoo.com> scribbled the following:

and maybe strcpy() should go too since it does not (cannot)
check how much it can copy? Long live to memcpy()!

Umm... have you heard of strlen()?

If u suggest calling strlen() before calling strcpy() *EVERY TIME*,
u are suggesting yet another problem. It's so easy to blow strlen().

STOP the rude top-posting, please. The point is not that it is
possible to misuse strcpy and strlen, but that it is impossible to
prevent misuse of gets. You can only 'blow' strlen if you apply
it to something that is not a string, in the C sense. You always
have control over the creation of that string.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #19

Alan Balmer

On 10 Dec 2003 22:36:38 -0800, wv****@yahoo.com (Will) wrote:

If u suggest calling strlen() before calling strcpy() *EVERY TIME*, u
are suggesting yet another problem. It's so easy to blow strlen().
Please don't top-post. Please stop the annoying practice of writing
"u" when you mean "you."

What Joona was suggesting was that you use strlen whenever needed to
determine the length of a string. Not "never", not "always", but
whenever the situation calls for it. But you already knew that, didn't
you?
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<br**********@oravannahka.helsinki.fi>...
Will <wv****@yahoo.com> scribbled the following:
> and maybe strcpy() should go too since it does not (cannot) check how much
> it can copy? Long live to memcpy()!

Umm... have you heard of strlen()?

--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 14 '05 #20

Shuo Xiang

Greetings:

gets() exists for the same reason as the standard streams handling
functions such as printf() and scanf() -- it simply makes your program
look more cleaner and concise.

The standard streams are holy, their names are NOT to be casually
mentioned in the context of a C program, just as the Catholics do not
say the name of God -- Jehovah, casually ;-)

fgets() still has its own share of problems, beside the complicated
setup, for example, how do you make sure that you have gotten
everything the user put it? I think the most fool-proof way would be
to make a character-based finite-state-machine that reacts to each one
of the user's keystrokes in a specific manner. Much like an arcade
machine that senses the subtlest of the user movements. But then
that's overboard for Standard C and toy programs.

Regards,

Shuo Xiang

Da*****@cern.ch (Dan Pop) wrote in message news:<br**********@sunnews.cern.ch>...

In <br**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
In <br**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
> In <bq**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:
>>gets() is universally acknowledged to be broken and useless; however,
>>it is still part of the standard library. Why? Is there enough
>>conforming code out there using gets() to justify retaining it? Are
>>there plans to deprecate or eliminate it in a future version? The committee (lame) excuse is that their job was to standardise
> existing practice and gets was existing practice. And, because it is
> standardised, now, it continues to be existing practice, so there is no
> hope to see it removed from the standard.

This begs the question, why was it existing practice in the first place?
What daemon possessed Dennis Ritchie to ever conceive it? What makes you think gets() is Ritchie's brainchild? There is no mention
of gets() in K&R1 at all...

What made me think it was Ritchie's brainchild is that it's quite a
basic C function, and C is Ritchie's brainchild.

That's very poor reasoning. The C we're talking about here hardly
qualifies as Ritchie's brainchild.
But I haven't read K&R1 in a while, so I forgot it wasn't there.

When was the last time you read it? ;-)
But the question remains: why did *anyone* invent gets() in the first
place?

For the same reason zillions of other people think that it is a good idea
to use it: it's much easier to use than fgets. Apart from that, there is
really nothing wrong with using gets() in toy programs, that are not
meant to be used by anyone but you and which are deleted as soon as they
have been fully debugged.

If you're perfectly aware of the safety issues involved, you can decide
when to use gets() and when not. There is little point in putting more
safety into a program than actually needed, especially considering that
this extra safety is not obtained for free.

Dan

Nov 14 '05 #21

Shuo Xiang wrote:

gets() exists for the same reason as the standard streams handling
functions such as printf() and scanf() -- it simply makes your
program look more cleaner and concise.

No it doesn't. It makes you look sloppy and ignorant. Read the
faq. And, in future, please DO NOT top-post. Your answer goes
after the material to which you are replying, after you have
deleted anything irrelevant to your reply. Top-posting after
being advised against it not only makes you look sloppy and
ignorant, it also marks you as rude.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #22

Kelsey Bjarnason

On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:

Shuo Xiang wrote:

gets() exists for the same reason as the standard streams handling
functions such as printf() and scanf() -- it simply makes your
program look more cleaner and concise.
No it doesn't.

Actually, it does:

char buff[128];
gets(buff);

vs

char buff[128];
fgets( buff, sizeof(buff),stdin);

The former is, indeed, cleaner and more concise.
It makes you look sloppy and ignorant.

However, it also has that effect. The two aren't exclusive. :)

Nov 14 '05 #23

Kelsey Bjarnason wrote:

On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:
Shuo Xiang wrote:

gets() exists for the same reason as the standard streams handling
functions such as printf() and scanf() -- it simply makes your
program look more cleaner and concise.

No it doesn't.

Actually, it does:

char buff[128];
gets(buff);

vs

char buff[128];
fgets( buff, sizeof(buff),stdin);

The former is, indeed, cleaner and more concise.

Oh very well, with the following proviso :-)

It makes you look sloppy and ignorant.

However, it also has that effect. The two aren't exclusive. :)

Oh for orthagonality :-) Which is why I recommend:

char * buf;
int err;
....
while (0 == (err = ggets(&buf))) {
/* do things with buf */
free(buf);
}

which can also be dumbed down to:

char * buf;
ggets(&buf);

with safety. See <http://cbfalconer.home.att.net/download/> My
philosophy for ggets was to preserve the utter simplicity of gets
without the penalty.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #24

Eric

Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:

On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:
It makes you look sloppy and ignorant.

However, it also has that effect. The two aren't exclusive. :)

Nonsense.

There are perfectly legitimate uses for gets that would do nothing of
the sort. Although, those cases would always (as near as I can
determine) imply that buffer overflow would not be an troublesome issue.

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #25

eg*************@verizon.net (Eric) writes:

Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:
It makes you look sloppy and ignorant.

However, it also has that effect. The two aren't exclusive. :)

Nonsense.

There are perfectly legitimate uses for gets that would do nothing of
the sort. Although, those cases would always (as near as I can
determine) imply that buffer overflow would not be an troublesome issue.

gets() can be used safely *only* if you have absolute control over
what the program will see on stdin. In typical environments, this
requires guaranteeing that the program using gets() cannot be invoked
directly by a user.

Even in such a context, fets() would serve the same purpose at the
expense of perhaps a tiny amount of extra code (passing two extra
arguments and allowing for the newline character that fgets() leaves
in the buffer). Personally, that's a price I will gladly pay rather
than having to prove, both to myself and to anyone who might read or
maintain the code, that a particular usage of gets() is actually safe.

I've never heard of an actual case of gets() being used safely in this
mannger, but I've seen numerous cases of it being used unsafely. (If
I recall correctly, the 1988 Morris Worm exploited one such unsafe
usage.)

The results of a buffer overflow, if you fail to prevent it, can vary
depending on the nature of the program in which it occurs. If it's in
something that has special privileges (e.g., in Unix terms, a daemon
running as root), the results can be almost arbitrarily bad. If it's
in a small unprivileged program whose failure won't cause any real
harm, it's not so bad -- but it still makes the programmer look
"sloppy and ignorant".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Nov 14 '05 #26

Eric

Keith Thompson <ks***@mib.org> wrote:

eg*************@verizon.net (Eric) writes:
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:

> It makes you look sloppy and ignorant.

However, it also has that effect. The two aren't exclusive. :)

Nonsense.

There are perfectly legitimate uses for gets that would do nothing of
the sort. Although, those cases would always (as near as I can
determine) imply that buffer overflow would not be a troublesome issue.

gets() can be used safely *only* if you have absolute control over
what the program will see on stdin. In typical environments, this
requires guaranteeing that the program using gets() cannot be invoked
directly by a user.

Even in such a context, fets() would serve the same purpose at the
expense of perhaps a tiny amount of extra code (passing two extra
arguments and allowing for the newline character that fgets() leaves
in the buffer). Personally, that's a price I will gladly pay rather
than having to prove, both to myself and to anyone who might read or
maintain the code, that a particular usage of gets() is actually safe.

Unless, of course, you don't have those extra bytes to spare that an
implementation of fgets() would need which gets does not.

In which case, you would be deemed a hero, by your boss, for getting
something to work which someone who had an irrational and absolute
hatred of gets() could not.

Would you really tell your boss that 'it can't be done' simply because
you would not use gets() and therefore be labeled sloppy and ignorant by
certain members of comp.lang.c?

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #27

Ben Pfaff

eg*************@verizon.net (Eric) writes:

Unless, of course, you don't have those extra bytes to spare that an
implementation of fgets() would need which gets does not.

In which case, you would be deemed a hero, by your boss, for getting
something to work which someone who had an irrational and absolute
hatred of gets() could not.

A better solution would be to write a function that does not
store a trailing new-line, but does take a buffer length.

Nov 14 '05 #28

Eric

Ben Pfaff <bl*@cs.stanford.edu> wrote:

eg*************@verizon.net (Eric) writes:
Unless, of course, you don't have those extra bytes to spare that an
implementation of fgets() would need which gets() does not.

In which case, you would be deemed a hero, by your boss, for getting
something to work which someone who had an irrational and absolute
hatred of gets() could not.

A better solution would be to write a function that does not
store a trailing new-line, but does take a buffer length.

Unless, again, you don't have even the tiny bit of space for such a
thing. (hint: you will need some code to check the buffer length)

Whether you are willing to accept it or not, there simply do exist cases
where there is very little room to play around in and each and every bit
is important and cannot be wasted unnecessarily.

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #29

Ben Pfaff

eg*************@verizon.net (Eric) writes:

Ben Pfaff <bl*@cs.stanford.edu> wrote:
eg*************@verizon.net (Eric) writes:
Unless, of course, you don't have those extra bytes to spare that an
implementation of fgets() would need which gets() does not.

In which case, you would be deemed a hero, by your boss, for getting
something to work which someone who had an irrational and absolute
hatred of gets() could not.

A better solution would be to write a function that does not
store a trailing new-line, but does take a buffer length.

Unless, again, you don't have even the tiny bit of space for such a
thing. (hint: you will need some code to check the buffer length)

Drop gets() and fgets() from the library on your device and you
will have plenty of room. Since your device is so small, there
is almost certainly a way to do that.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

Nov 14 '05 #30

Eric wrote:

Keith Thompson <ks***@mib.org> wrote:
eg*************@verizon.net (Eric) writes:
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
> On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:
>
> > It makes you look sloppy and ignorant.
>
> However, it also has that effect. The two aren't exclusive. :)

Nonsense.

There are perfectly legitimate uses for gets that would do nothing of
the sort. Although, those cases would always (as near as I can
determine) imply that buffer overflow would not be a troublesome issue.

gets() can be used safely *only* if you have absolute control over
what the program will see on stdin. In typical environments, this
requires guaranteeing that the program using gets() cannot be invoked
directly by a user.

Even in such a context, fets() would serve the same purpose at the
expense of perhaps a tiny amount of extra code (passing two extra
arguments and allowing for the newline character that fgets() leaves
in the buffer). Personally, that's a price I will gladly pay rather
than having to prove, both to myself and to anyone who might read or
maintain the code, that a particular usage of gets() is actually safe.

Unless, of course, you don't have those extra bytes to spare that an
implementation of fgets() would need which gets does not.

In which case, you would be deemed a hero, by your boss, for getting
something to work which someone who had an irrational and absolute
hatred of gets() could not.

Would you really tell your boss that 'it can't be done' simply because
you would not use gets() and therefore be labeled sloppy and ignorant
by certain members of comp.lang.c?

No, I would write something like the following, and cackle:

#include stdio.h
#define MAXLGH 123

void inputline(char * buf)
{
int i = 0;
int ch;

while (EOF != (ch = getchar())) {
if ('\n' == ch) break;
if (i < MAXLGH-1) buf[i++] = ch;
}
buf[i] = '\0';
}

and encourage the users to declare char arrays of size MAXLGH. I
could also be persuaded to return some status information rather
than the void.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #31

Eric

Ben Pfaff <bl*@cs.stanford.edu> wrote:

eg*************@verizon.net (Eric) writes:
Ben Pfaff <bl*@cs.stanford.edu> wrote:
eg*************@verizon.net (Eric) writes:

> Unless, of course, you don't have those extra bytes to spare that an
> implementation of fgets() would need which gets() does not.
>
> In which case, you would be deemed a hero, by your boss, for getting
> something to work which someone who had an irrational and absolute
> hatred of gets() could not.

A better solution would be to write a function that does not
store a trailing new-line, but does take a buffer length.

Unless, again, you don't have even the tiny bit of space for such a
thing. (hint: you will need some code to check the buffer length)

Drop gets() and fgets() from the library on your device and you
will have plenty of room. Since your device is so small, there
is almost certainly a way to do that.

Unless, of course, that has already been done.

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #32

Eric

CBFalconer <cb********@yahoo.com> wrote:

Eric wrote:
Keith Thompson <ks***@mib.org> wrote:
eg*************@verizon.net (Eric) writes:
> Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
> > On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:
> >
> > > It makes you look sloppy and ignorant.
> >
> > However, it also has that effect. The two aren't exclusive. :)
>
> Nonsense.
>
> There are perfectly legitimate uses for gets that would do nothing of
> the sort. Although, those cases would always (as near as I can
> determine) imply that buffer overflow would not be a troublesome issue.

gets() can be used safely *only* if you have absolute control over
what the program will see on stdin. In typical environments, this
requires guaranteeing that the program using gets() cannot be invoked
directly by a user.

Even in such a context, fets() would serve the same purpose at the
expense of perhaps a tiny amount of extra code (passing two extra
arguments and allowing for the newline character that fgets() leaves
in the buffer). Personally, that's a price I will gladly pay rather
than having to prove, both to myself and to anyone who might read or
maintain the code, that a particular usage of gets() is actually safe.

Unless, of course, you don't have those extra bytes to spare that an
implementation of fgets() would need which gets does not.

In which case, you would be deemed a hero, by your boss, for getting
something to work which someone who had an irrational and absolute
hatred of gets() could not.

Would you really tell your boss that 'it can't be done' simply because
you would not use gets() and therefore be labeled sloppy and ignorant
by certain members of comp.lang.c?

No, I would write something like the following, and cackle:

#include stdio.h
#define MAXLGH 123

void inputline(char * buf)
{
int i = 0;
int ch;

while (EOF != (ch = getchar())) {
if ('\n' == ch) break;
if (i < MAXLGH-1) buf[i++] = ch;
}
buf[i] = '\0';
}

and encourage the users to declare char arrays of size MAXLGH. I
could also be persuaded to return some status information rather
than the void.

'The check of the buffer length put you over pre-defined limits. We're
going with another person who understands our situation. You're fired.'
--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #33

Ben Pfaff

eg*************@verizon.net (Eric) writes:

Ben Pfaff <bl*@cs.stanford.edu> wrote:
eg*************@verizon.net (Eric) writes:
Ben Pfaff <bl*@cs.stanford.edu> wrote:

> eg*************@verizon.net (Eric) writes:
>
> > Unless, of course, you don't have those extra bytes to spare that an
> > implementation of fgets() would need which gets() does not.
> >
> > In which case, you would be deemed a hero, by your boss, for getting
> > something to work which someone who had an irrational and absolute
> > hatred of gets() could not.
>
> A better solution would be to write a function that does not
> store a trailing new-line, but does take a buffer length.

Unless, again, you don't have even the tiny bit of space for such a
thing. (hint: you will need some code to check the buffer length)

Drop gets() and fgets() from the library on your device and you
will have plenty of room. Since your device is so small, there
is almost certainly a way to do that.

Unless, of course, that has already been done.

Then how are you going to use gets(), as in your suggestion?
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

Nov 14 '05 #34

Chris Torek

In article <news:ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:

I've never heard of an actual case of gets() being used safely in this
manner, but I've seen numerous cases of it being used unsafely. (If
I recall correctly, the 1988 Morris Worm exploited one such unsafe
usage.)

Yes. The Morris Worm had two primary methods of ingress. One used
a security hole in sendmail -- the hole itself was actually a
deliberate option, although its being enabled on virtually every
machine running sendmail was not, and the less said about this the
better :-) (though I have no personal stake in it) -- and the other
used the fact that the finger daemon had:

char buf[512];
...
gets(buf);

in it, with a 512-byte "buf". (The program's stdin was, at this
point, connected to the network "finger" port, TCP port 79.)

This was perhaps the first remote buffer-overflow exploit, and
certainly the first really major one. The lesson it taught has
been learned over and over by (I believe) hundreds of millions of
(mostly Microsoft) users, but apparently not by server-writers. :-)

(The University of Maryland's CS department, where I worked at the
time, managed to fend off the worm, in part because I had replaced
the finger daemon. Mine even logged the overflow attempts -- Pete
Cottrell got on the local TV news with a screen shot of finger log
file entries. [I was in Berkeley at the time.] The other part
was because Steve Miller had done a lot of sendmail work, closing
the hole.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Nov 14 '05 #35

On Fri, 12 Dec 2003 17:45:17 -0500, in comp.lang.c ,
eg*************@verizon.net (Eric) wrote:

Would you really tell your boss that 'it can't be done' simply because
you would not use gets()
I'd tell him that I could do it, but only at the expense of
introducing a known and serious bug into the code which provided a
real risk of the programme crashing under perfectly normal conditions.
If he still wanted to do it, then I'd put it in writing, do it, and
send my resume out.
and therefore be labeled sloppy and ignorant by
certain members of comp.lang.c?

I can think of worse things to be called. The sort of programmer who
uses gets and crashes the air traffic control system of Chicago
Airport for example.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 14 '05 #36

Eric

Ben Pfaff <bl*@cs.stanford.edu> wrote:

eg*************@verizon.net (Eric) writes:
Ben Pfaff <bl*@cs.stanford.edu> wrote:
eg*************@verizon.net (Eric) writes:

> Ben Pfaff <bl*@cs.stanford.edu> wrote:
>
> > eg*************@verizon.net (Eric) writes:
> >
> > > Unless, of course, you don't have those extra bytes to spare that an
> > > implementation of fgets() would need which gets() does not.
> > >
> > > In which case, you would be deemed a hero, by your boss, for getting
> > > something to work which someone who had an irrational and absolute
> > > hatred of gets() could not.
> >
> > A better solution would be to write a function that does not
> > store a trailing new-line, but does take a buffer length.
>
> Unless, again, you don't have even the tiny bit of space for such a
> thing. (hint: you will need some code to check the buffer length)

Drop gets() and fgets() from the library on your device and you
will have plenty of room. Since your device is so small, there
is almost certainly a way to do that.

Unless, of course, that has already been done.

Then how are you going to use gets(), as in your suggestion?

Why are you going to insist on putting in an absolutely unnecessary
buffer check in the subset of cases I am talking about, making the
problem unsolvable?
--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #37

Eric

Mark McIntyre <ma**********@spamcop.net> wrote:

On Fri, 12 Dec 2003 17:45:17 -0500, in comp.lang.c ,
eg*************@verizon.net (Eric) wrote:
Would you really tell your boss that 'it can't be done' simply because
you would not use gets()

I'd tell him that I could do it, but only at the expense of
introducing a known and serious bug into the code which provided a
real risk of the programme crashing under perfectly normal conditions.

So, you disagree with Keith Thompson who stated:

'gets() can be used safely *only* if you have absolute
control over what the program will see on stdin.'

?

You believe there absolutely does not exist any case where gets() can be
used safely?

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #38

On 12 Dec 2003 15:45:55 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.edu> wrote:

Ben,

_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 14 '05 #39

Arthur J. O'Dwyer

On Fri, 12 Dec 2003, Eric wrote:

Ben Pfaff <bl*@cs.stanford.edu> wrote:
A better solution would be to write a function that does not
store a trailing new-line, but does take a buffer length.

Unless, again, you don't have even the tiny bit of space for such a
thing. (hint: you will need some code to check the buffer length)

Whether you are willing to accept it or not, there simply do exist cases
where there is very little room to play around in and each and every bit
is important and cannot be wasted unnecessarily.

Now, I may be naive, but it seems to me that it is in those
situations where absolutely every byte in your program space is
significant that you would want to take the *most* care not to
stomp on any of those bytes.
One reason Windows can get away with so many loopholes and
overruns is because it bloats out over the entire RAM, so that
only a few overruns actually hit anything mission-critical (cf.
Core Wars). On a machine with very little RAM, presumably all your
mission-critical stuff is packed real close together, and a buffer
overrun of only two or three bytes could be absolutely disastrous.
In such a case, a competent programmer would certainly want to
protect his code! He'd use a format-checking input function like
scanf() or fgets(), not a RAM-stomping free-for-all like gets().

-Arthur

Nov 14 '05 #40

On Fri, 12 Dec 2003 18:59:19 -0500, in comp.lang.c ,
eg*************@verizon.net (Eric) wrote:

Mark McIntyre <ma**********@spamcop.net> wrote:
I'd tell him that I could do it, but only at the expense of
introducing a known and serious bug into the code which provided a
real risk of the programme crashing under perfectly normal conditions.
So, you disagree with Keith Thompson who stated:

'gets() can be used safely *only* if you have absolute
control over what the program will see on stdin.'

My statement in no way disagrees with Keith. Except in your mind of
course.

You sir, are a troll. Go back under your rock.
You believe there absolutely does not exist any case where gets() can be
used safely?

I believe there's absolutely no point in arguing with a troll.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 14 '05 #41

Eric

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote:

On Fri, 12 Dec 2003, Eric wrote:

Ben Pfaff <bl*@cs.stanford.edu> wrote:
A better solution would be to write a function that does not
store a trailing new-line, but does take a buffer length.

Unless, again, you don't have even the tiny bit of space for such a
thing. (hint: you will need some code to check the buffer length)

Whether you are willing to accept it or not, there simply do exist cases
where there is very little room to play around in and each and every bit
is important and cannot be wasted unnecessarily.

Now, I may be naive, but it seems to me that it is in those
situations where absolutely every byte in your program space is
significant that you would want to take the *most* care not to
stomp on any of those bytes.

Agreed. However, I am not speaking about cases where that would be a
worry.

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #42

Eric

Mark McIntyre <ma**********@spamcop.net> wrote:

On Fri, 12 Dec 2003 18:59:19 -0500, in comp.lang.c ,
eg*************@verizon.net (Eric) wrote:
Mark McIntyre <ma**********@spamcop.net> wrote:
I'd tell him that I could do it, but only at the expense of
introducing a known and serious bug into the code which provided a
real risk of the programme crashing under perfectly normal conditions.

So, you disagree with Keith Thompson who stated:

'gets() can be used safely *only* if you have absolute
control over what the program will see on stdin.'
?

My statement in no way disagrees with Keith.

I would include under the heading of a 'safe use of gets()' that there
would be no risk of crashing under perfectly normal conditions.

When you have absolute control over what the program will see on stdin,
this potential does not exist.

If one cannot guarantee absolute control, gets() should not be used.

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #43

eg*************@verizon.net (Eric) writes:

Keith Thompson <ks***@mib.org> wrote:
eg*************@verizon.net (Eric) writes:
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
> On Thu, 11 Dec 2003 17:30:20 +0000, CBFalconer wrote:
> > It makes you look sloppy and ignorant.
> However, it also has that effect. The two aren't exclusive. :)
Nonsense.

There are perfectly legitimate uses for gets that would do nothing of
the sort. Although, those cases would always (as near as I can
determine) imply that buffer overflow would not be a troublesome issue.

gets() can be used safely *only* if you have absolute control over
what the program will see on stdin. In typical environments, this
requires guaranteeing that the program using gets() cannot be invoked
directly by a user.

Even in such a context, fets() would serve the same purpose at the
expense of perhaps a tiny amount of extra code (passing two extra
arguments and allowing for the newline character that fgets() leaves
in the buffer). Personally, that's a price I will gladly pay rather
than having to prove, both to myself and to anyone who might read or
maintain the code, that a particular usage of gets() is actually safe.

Unless, of course, you don't have those extra bytes to spare that an
implementation of fgets() would need which gets does not.

In which case, you would be deemed a hero, by your boss, for getting
something to work which someone who had an irrational and absolute
hatred of gets() could not.

Would you really tell your boss that 'it can't be done' simply because
you would not use gets() and therefore be labeled sloppy and ignorant by
certain members of comp.lang.c?

My hatred of gets() is neither irrational nor absolute.

It's unlikely that a hosted implementation would have such tight
memory constraints. A freestanding implementation need not provide
the standard I/O library at all.

Overall, it's extremely unlikely that the tiny amount of extra memory
(code and/or data) required to use fgets() rather than gets() is going
to be significant. If you run into such a situation in real life,
feel free to come back and tell us about it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Nov 14 '05 #44

Eric

Keith Thompson <ks***@mib.org> wrote:

It's unlikely that a hosted implementation would have such tight
memory constraints. A freestanding implementation need not provide
the standard I/O library at all.

Overall, it's extremely unlikely that the tiny amount of extra memory
(code and/or data) required to use fgets() rather than gets() is going
to be significant.

Agreed.

Quite rare or unlikely, but not out of the question and most certainly
would not make someone look look sloppy and ignorant, which had been
asserted.

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #45

eg*************@verizon.net (Eric) writes:

Keith Thompson <ks***@mib.org> wrote:
It's unlikely that a hosted implementation would have such tight
memory constraints. A freestanding implementation need not provide
the standard I/O library at all.

Overall, it's extremely unlikely that the tiny amount of extra memory
(code and/or data) required to use fgets() rather than gets() is going
to be significant.

Agreed.

Quite rare or unlikely, but not out of the question and most certainly
would not make someone look look sloppy and ignorant, which had been
asserted.

Using gets() makes you look sloppy and ignorant. The cases where it's
justified are so rare that they're hardly worth considering.

If I ever saw a legitimate use of gets(), my first reaction would be
that the programmer should have known enough to use fgets() instead.
My second reaction, after spending a few minutes reading the comment
explaining exactly why gets() is more appropriate than fgets() in this
context, would be astonishment. (Lacking such a comment, I wouldn't
get past my first reaction).

Historical note: The Morris Worm hit in 1988, while ANSI was working
on the first C standard. I wonder why that wasn't enough to persuade
the committee to deprecate gets().

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Nov 14 '05 #46

On Sat, 13 Dec 2003 04:39:40 GMT, in comp.lang.c ,
eg*************@verizon.net (Eric) wrote:

Keith Thompson <ks***@mib.org> wrote:
Overall, it's extremely unlikely that the tiny amount of extra memory
(code and/or data) required to use fgets() rather than gets() is going
to be significant.
Agreed.

Quite rare or unlikely, but not out of the question

Agreedand most certainly
would not make someone look look sloppy and ignorant, which had been
asserted.

I disagree as vigorously as you troll. /Any/ use of gets is poor
program design, memory constraints notwithstanding. I'd expect any
programmer using it to be able to explain precisely why he was utterly
convinced that there was no chance ever of it causing a problem.

And I do mean /ever/, not merely "in the program's current
incarnation" or "on the current hardware" or "in the current operating
environment".

His code that today reads from 80-char punched cards will tomorrow
read from 132-char cards, or from a pipe, or run on a machine with no
memory protection, or be used as a library function in a heart monitor
or nuclear missile silo.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 14 '05 #47

Eric

Keith Thompson <ks***@mib.org> wrote:

eg*************@verizon.net (Eric) writes:
Keith Thompson <ks***@mib.org> wrote:
It's unlikely that a hosted implementation would have such tight
memory constraints. A freestanding implementation need not provide
the standard I/O library at all.

Overall, it's extremely unlikely that the tiny amount of extra memory
(code and/or data) required to use fgets() rather than gets() is going
to be significant.

Agreed.

Quite rare or unlikely, but not out of the question and most certainly
would not make someone look look sloppy and ignorant, which had been
asserted.

Using gets() makes you look sloppy and ignorant. The cases where it's
justified are so rare that they're hardly worth considering.

If I ever saw a legitimate use of gets(), my first reaction would be
that the programmer should have known enough to use fgets() instead.
My second reaction, after spending a few minutes reading the comment
explaining exactly why gets() is more appropriate than fgets() in this
context, would be astonishment. (Lacking such a comment, I wouldn't
get past my first reaction).

So, you would really tell your boss that 'it can't be done' simply
because you would not use gets() and therefore be labeled sloppy and
ignorant by certain members of comp.lang.c.

--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===

Nov 14 '05 #48