Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > gets() rationale

Reply
Thread Tools

gets() rationale

 
 
Dan Pop
Guest
Posts: n/a
 
      12-09-2003
In <br4klt$q8s$(E-Mail Removed)> Joona I Palaste <(E-Mail Removed)> writes:

>Dan Pop <(E-Mail Removed)> scribbled the following:
>> In <bqj06o$8p9$(E-Mail Removed)> Christopher Benson-Manica <(E-Mail Removed)> 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...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Joona I Palaste
Guest
Posts: n/a
 
      12-10-2003
Dan Pop <(E-Mail Removed)> scribbled the following:
> In <br4klt$q8s$(E-Mail Removed)> Joona I Palaste <(E-Mail Removed)> writes:
>>Dan Pop <(E-Mail Removed)> scribbled the following:
>>> In <bqj06o$8p9$(E-Mail Removed)> Christopher Benson-Manica <(E-Mail Removed)> 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. But I haven't read
K&R1 in a while, so I forgot it wasn't there.
But the question remains: why did *anyone* invent gets() in the first
place?

--
/-- Joona Palaste ((E-Mail Removed)) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola
 
Reply With Quote
 
 
 
 
Dan Pop
Guest
Posts: n/a
 
      12-10-2003
In <br6lbl$2kq$(E-Mail Removed)> Joona I Palaste <(E-Mail Removed)> writes:

>Dan Pop <(E-Mail Removed)> scribbled the following:
>> In <br4klt$q8s$(E-Mail Removed)> Joona I Palaste <(E-Mail Removed)> writes:
>>>Dan Pop <(E-Mail Removed)> scribbled the following:
>>>> In <bqj06o$8p9$(E-Mail Removed)> Christopher Benson-Manica <(E-Mail Removed)> 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)
 
Reply With Quote
 
Will
Guest
Posts: n/a
 
      12-10-2003
and maybe strcpy() should go too since it does not (cannot) check how much
it can copy? Long live to memcpy()!

Christopher Benson-Manica <(E-Mail Removed)> wrote in message news:<bqj06o$8p9$(E-Mail Removed)>...
> 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?

 
Reply With Quote
 
Joona I Palaste
Guest
Posts: n/a
 
      12-10-2003
Will <(E-Mail Removed)> 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()?

--
/-- Joona Palaste ((E-Mail Removed)) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-11-2003
(E-Mail Removed) (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) (E-Mail Removed) <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)
 
Reply With Quote
 
Will
Guest
Posts: n/a
 
      12-11-2003
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 <(E-Mail Removed)> wrote in message news:<br87b1$2gu$(E-Mail Removed)>...
> Will <(E-Mail Removed)> 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()?

 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      12-11-2003

On Thu, 10 Dec 2003, Will wrote:
>
> Joona I Palaste <(E-Mail Removed)> wrote...
> > Will <(E-Mail Removed)> 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.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      12-11-2003
Will wrote: *** top posting fixed ***
> Joona I Palaste <(E-Mail Removed)> wrote in message
> > Will <(E-Mail Removed)> 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 ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
Alan Balmer
Guest
Posts: n/a
 
      12-11-2003
On 10 Dec 2003 22:36:38 -0800, (E-Mail Removed) (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 <(E-Mail Removed)> wrote in message news:<br87b1$2gu$(E-Mail Removed)>...
>> Will <(E-Mail Removed)> 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
(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Question about rationale for java.nio.Buffer design. Harald Kirsch Java 0 06-14-2004 12:15 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 42 04-06-2004 10:11 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 2 04-02-2004 08:49 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 2 04-01-2004 05:01 PM
Re: The Sigma-Foveon pixel rationale David J. Littleboy Digital Photography 2 04-01-2004 08:11 AM



Advertisments