gets() rationale

Discussion in 'C Programming' started by Christopher Benson-Manica, Dec 2, 2003.

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

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Dec 2, 2003
    #1
    1. Advertising

  2. Christopher Benson-Manica

    Eric Sosman Guest

    Christopher Benson-Manica wrote:
    >
    > 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?


    A question for comp.std.c, methinks. Follow-ups set.

    At a guess, the Committee did not feel at liberty to
    "reform" the traditional C library, even when hindsight
    showed some of its features could have been better designed.
    <varargs.h> was, I think, just about the only "subtraction,"
    and the reason was that its traditional form was pretty
    much unimplementable on certain machines of interest.

    --
    Eric Sosman, Dec 2, 2003
    #2
    1. Advertising

  3. Christopher Benson-Manica

    Ben Pfaff Guest

    Christopher Benson-Manica <> 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?


    Here is what the C99 rationale says:

    30 7.19.7.7 The gets function

    Because gets does not check for buffer overrun, it is
    generally unsafe to use when its input is not under the
    programmer's control. This has caused some to question
    whether it should appear in the Standard at all. The
    35 Committee decided that gets was useful and convenient in
    those special circumstances when the programmer does have
    adequate control over the input, and as longstanding
    existing practice, it needed a standard specification. In
    general, however, the preferred function is fgets (see
    §7.19.7.2).

    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x1f6},*p=
    b,x,i=24;for(;p+=!*p;*p/=4)switch(x=*p&3)case 0:{return 0;for(p--;i--;i--)case
    2:{i++;if(1)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
    Ben Pfaff, Dec 3, 2003
    #3
  4. Christopher Benson-Manica

    James Hu Guest

    On 2003-12-02, Christopher Benson-Manica <> wrote:
    > 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?


    A C compiler could generate a diagnostic when functions that are known
    to be unsafe are used and suggest a safer alternative instead. (I seem
    to remember seeing such warnings on the BSD version of gcc.)

    -- James
    James Hu, Dec 3, 2003
    #4
  5. Christopher Benson-Manica

    Dan Pop Guest

    In <> James Hu <> writes:

    >On 2003-12-02, Christopher Benson-Manica <> wrote:
    >> 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?

    >
    >A C compiler could generate a diagnostic when functions that are known
    >to be unsafe are used and suggest a safer alternative instead. (I seem
    >to remember seeing such warnings on the BSD version of gcc.)


    It's actually the linker that does it:

    fangorn:~/tmp 26> gcc -c test.c
    fangorn:~/tmp 27> gcc test.o
    test.o: In function `main':
    test.o(.text+0x7): the `gets' function is dangerous and should not be used.

    Generating such warnings is a feature of GNU ld.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Dec 3, 2003
    #5
  6. Christopher Benson-Manica

    Dan Pop Guest

    In <bqj06o$8p9$> Christopher Benson-Manica <> 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.

    The real solution would have been to deprecate it in C89 and remove it in
    C99. If some C99 program needed it badly, implementing gets() is a piece
    of cake and a C99 program would have been allowed to define it. But they
    missed the opportunity to fix this bug in the language and they are also
    convinced that they did the right thing...

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Dec 3, 2003
    #6
  7. Dan Pop <> scribbled the following:
    > In <bqj06o$8p9$> Christopher Benson-Manica <> 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?

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "My absolute aspect is probably..."
    - Mato Valtonen
    Joona I Palaste, Dec 9, 2003
    #7
  8. Christopher Benson-Manica

    Eric Guest

    Joona I Palaste <> wrote:

    > This begs the question, why was it existing practice in the first place?
    > What daemon possessed Dennis Ritchie to ever conceive it?


    Perhaps because of space limitations.

    Once upon a time every single last byte was important and gets works
    just fine and is all one needs in certain cases.



    --
    == 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... ===
    Eric, Dec 9, 2003
    #8
  9. Christopher Benson-Manica

    P.J. Plauger Guest

    "Eric" <> wrote in message
    news:1g5p6nt.1jvc9pj1cxy8weN%...

    > Joona I Palaste <> wrote:
    >
    > > This begs the question, why was it existing practice in the first place?
    > > What daemon possessed Dennis Ritchie to ever conceive it?

    >
    > Perhaps because of space limitations.
    >
    > Once upon a time every single last byte was important and gets works
    > just fine and is all one needs in certain cases.


    I don't know for sure, but I doubt that DMR is the perpetrator of
    gets. For a period of time in the mid/late 1970s, all sorts of
    people were throwing functions into the C library (and applications
    into the set of Unix tools, and even system calls into the Unix
    kernel). Not all of these were well thought out.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
    P.J. Plauger, Dec 9, 2003
    #9
  10. Christopher Benson-Manica

    Les Cargill Guest

    Joona I Palaste wrote:
    >
    > Dan Pop <> scribbled the following:
    > > In <bqj06o$8p9$> Christopher Benson-Manica <> 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?
    >


    The 'C' libraries evoved, and were not necessarily designed from a
    rigorous set of requirements ( beyond what they were designed from).

    "Doctor, doctor, it hurts when I do that."
    "Well, don't do that."

    > --
    > /-- Joona Palaste () ------------- Finland --------\
    > \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    > "My absolute aspect is probably..."
    > - Mato Valtonen



    --
    Les Cargill
    Les Cargill, Dec 9, 2003
    #10
  11. Christopher Benson-Manica

    Dan Pop Guest

    In <br4klt$q8s$> Joona I Palaste <> writes:

    >Dan Pop <> scribbled the following:
    >> In <bqj06o$8p9$> Christopher Benson-Manica <> 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:
    Dan Pop, Dec 9, 2003
    #11
  12. Dan Pop <> scribbled the following:
    > In <br4klt$q8s$> Joona I Palaste <> writes:
    >>Dan Pop <> scribbled the following:
    >>> In <bqj06o$8p9$> Christopher Benson-Manica <> 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 () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "And according to Occam's Toothbrush, we only need to optimise the most frequent
    instructions."
    - Teemu Kerola
    Joona I Palaste, Dec 10, 2003
    #12
  13. Christopher Benson-Manica

    Dan Pop Guest

    In <br6lbl$2kq$> Joona I Palaste <> writes:

    >Dan Pop <> scribbled the following:
    >> In <br4klt$q8s$> Joona I Palaste <> writes:
    >>>Dan Pop <> scribbled the following:
    >>>> In <bqj06o$8p9$> Christopher Benson-Manica <> 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:
    Dan Pop, Dec 10, 2003
    #13
  14. Christopher Benson-Manica

    Will Guest

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

    Christopher Benson-Manica <> wrote in message news:<bqj06o$8p9$>...
    > 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?
    Will, Dec 10, 2003
    #14
  15. Will <> 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 () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "It's time, it's time, it's time to dump the slime!"
    - Dr. Dante
    Joona I Palaste, Dec 10, 2003
    #15
  16. (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) <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)
    Keith Thompson, Dec 11, 2003
    #16
  17. Christopher Benson-Manica

    Will Guest

    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 <> wrote in message news:<br87b1$2gu$>...
    > Will <> 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()?
    Will, Dec 11, 2003
    #17
  18. On Thu, 10 Dec 2003, Will wrote:
    >
    > Joona I Palaste <> wrote...
    > > Will <> 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.
    Arthur J. O'Dwyer, Dec 11, 2003
    #18
  19. Christopher Benson-Manica

    CBFalconer Guest

    Will wrote: *** top posting fixed ***
    > Joona I Palaste <> wrote in message
    > > Will <> 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 () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Dec 11, 2003
    #19
  20. Christopher Benson-Manica

    Alan Balmer Guest

    On 10 Dec 2003 22:36:38 -0800, (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 <> wrote in message news:<br87b1$2gu$>...
    >> Will <> 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
    Alan Balmer, Dec 11, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harald Kirsch
    Replies:
    0
    Views:
    366
    Harald Kirsch
    Jun 14, 2004
  2. Stefan Mueller
    Replies:
    5
    Views:
    507
    Steven Saunderson
    Jul 10, 2006
  3. John Joyce

    gets gets

    John Joyce, Mar 26, 2007, in forum: Ruby
    Replies:
    2
    Views:
    336
    John Joyce
    Mar 26, 2007
  4. John Joyce

    Return of gets gets

    John Joyce, Apr 23, 2007, in forum: Ruby
    Replies:
    0
    Views:
    183
    John Joyce
    Apr 23, 2007
  5. libsfan01
    Replies:
    5
    Views:
    229
    Jeff North
    Dec 20, 2006
Loading...

Share This Page