Topic: Why "gets" has not been deprecated yet?


Author: clarkcox3@gmail.com ("Clark S. Cox III")
Date: Fri, 11 Nov 2005 05:41:19 GMT
Raw View
On 2005-11-09 23:05:15 -0500, squell@alumina.nl (Marc Schoolderman) said:

> Charlie Stott wrote:
>
>>>> What functionality do you expect?
>>>> a) <bool> will be inverted
>>>> b) <bool> will be incremented (what type is <bool> based on?)?
>>>> if a) then use !=, if b) then why are you using <bool>?
>>> (++b) and (b = true) are equivalent.
>> So, why would you need to use (++b), when there is a more suitable alternative?
>
> That by itself does not justify deprecation, though.
>
>> What if (<bool> == MAX_INT)?
>
> Not a problem, by definition. The only thing I can think of is that it
> causes the following 'surprising' behavior:
>
> bool x; ++x; ++x; --x;    // x == false

No, this won't happen, as the -- operator cannot be applied to bool's.

--
Clark S. Cox, III
clarkcox3@gmail.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: richard@ex-parrot.com
Date: Thu, 10 Nov 2005 23:41:13 CST
Raw View
Marc Schoolderman wrote:
> Not a problem, by definition. The only thing I can think of is that it
> causes the following 'surprising' behavior:
>
> bool x; ++x; ++x; --x;    // x == false

No.  x is not false because the code should not even compile.  There is
no operator-- on booleans.

--
Richard Smith

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Marc Schoolderman <squell@alumina.nl>
Date: Fri, 11 Nov 2005 22:07:14 CST
Raw View
Clark S. Cox III wrote:

>> Not a problem, by definition. The only thing I can think of is that it
>> causes the following 'surprising' behavior:
>> bool x; ++x; ++x; --x;    // x == false
> No, this won't happen, as the -- operator cannot be applied to bool's.

Indeed, very quickly noted that after posting (obviously, I don't _use_
either operator on bools!;)

Charlie Stott wrote:

 >>> What if (<bool> == MAX_INT)?
 >> Your (pre-standard) code breaks.
 > I think the point has been made...

Not really, because standard code will not break, and a change from
pre-standard C++ is hardly a reason for deprecation.

Note that I am not arguing in favor of the coding style "bool++" (or
arguing for un-deprecation). The point is the exact criteria which the
Standard committee uses to deprecate something. This thread wasn't the
first where someone advocated deprecating a feature as a way to coerce
programmers into abandoning something one simply doesn't like.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "Marcus" <yuu@yyhmail.com>
Date: Wed, 2 Nov 2005 23:30:03 CST
Raw View
(posted originally on comp.lang.c++)

We all know that the "gets" function from the Standard C Library (which
is part of the Standard C++ Library) is dangerous. It provides no
bounds check, so it's easy to overwrite memory when using it, and
impossible to guarantee that it won't happen.

Therefore, i think it's surprising that this function has not been
deprecated.
The C++98 Standard keeps it from the C89 standard.
The C99 Standard has kept it :-o.

Now, the C standard committee is working on safe functions (the ones
that end with "_s") for the C Standard Library. I don't know if they
are going to deprecate the dreaded "gets". Even if not, i think it
would be a good idea to deprecate it in the next C++ standard, since
C++ has better ways to accomplish the same task (getline). It's too
early to expect the safe functions (*_s) in the C++ Standard, but
getting rid of "gets" is not that hard, isn't it? Programs that use it
are broken anyway ( ;-) ). Also, C++ has deprecated other features from
C just
because C++ has better alternatives (static meaning "internal linkage"
and headers ending in ".h").

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Niklas Matthies <usenet-nospam@nmhq.net>
Date: Thu, 3 Nov 2005 01:40:21 CST
Raw View
On 2005-11-03 05:30, Marcus wrote:
> (posted originally on comp.lang.c++)
>
> We all know that the "gets" function from the Standard C Library
> (which is part of the Standard C++ Library) is dangerous. It
> provides no bounds check, so it's easy to overwrite memory when
> using it, and impossible to guarantee that it won't happen.
>
> Therefore, i think it's surprising that this function has not been
> deprecated.

Deprecating it won't stop library vendors from providing it for
compatibility reasons, and won't stop incompetent programmers from
using it, while competent programmers won't use it in real code
whether it's deprecated or not. Presumably that's why it was
standardized in the first place and why the committees didn't
bother to deprecate it later on.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Paradoxum@gmail.com
Date: Thu, 3 Nov 2005 09:39:15 CST
Raw View
A staple of the C/C++ standards is backward compatibilty.  If you
deprecate any function provided in the Standard C Library, you could
risk future compilers not being able to compile probably hundreds of
thousands of programs floating around on the internet.

While gets is obviously a very dangerous function to use because of its
invitation for buffer overflowing, I have to agree with Niklas in that
incompetant programmers will likely will write potential buffer
overflows into their program whether they have gets or not.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: petebecker@acm.org (Pete Becker)
Date: Thu, 3 Nov 2005 15:40:44 GMT
Raw View
Niklas Matthies wrote:

>
> Deprecating it won't stop library vendors from providing it for
> compatibility reasons
>

Deprecating it would mean that it might be removed in the future. Until
that happened, it would continue to be required in a conforming
implementation.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "thoth39" <pedro.lamarao@gmail.com>
Date: Thu, 3 Nov 2005 09:40:38 CST
Raw View
> Deprecating it won't stop library vendors from providing it for
> compatibility reasons, and won't stop incompetent programmers from
> using it, while competent programmers won't use it in real code
> whether it's deprecated or not. Presumably that's why it was
> standardized in the first place and why the committees didn't
> bother to deprecate it later on.

Deprecating it could stimulate compiler writers to add warnings about
it's usage without removing the feeling of standard compliance.

-- Pedro Lamar   o


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Niklas Matthies <usenet-nospam@nmhq.net>
Date: Thu, 3 Nov 2005 11:47:43 CST
Raw View
On 2005-11-03 15:40, Pete Becker wrote:
> Niklas Matthies wrote:
>
>> Deprecating it won't stop library vendors from providing it for
>> compatibility reasons
>
> Deprecating it would mean that it might be removed in the future.
> Until that happened, it would continue to be required in a
> conforming implementation.

You're right, of course. It only supports the argument, though.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Niklas Matthies <usenet-nospam@nmhq.net>
Date: Thu, 3 Nov 2005 11:47:47 CST
Raw View
On 2005-11-03 15:40, thoth39 wrote:
>> Deprecating it won't stop library vendors from providing it for
>> compatibility reasons, and won't stop incompetent programmers from
>> using it, while competent programmers won't use it in real code
>> whether it's deprecated or not. Presumably that's why it was
>> standardized in the first place and why the committees didn't
>> bother to deprecate it later on.
>
> Deprecating it could stimulate compiler writers to add warnings about
> it's usage without removing the feeling of standard compliance.

It would remove the feeling of future standard compliance.
More importantly, warning about deprecation instead of about the
unsafeness of gets() would fail to communicate the actual point.

FWIW, GNU ld already warns about gets().

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: nagle@animats.com (John Nagle)
Date: Thu, 3 Nov 2005 18:32:07 GMT
Raw View
Niklas Matthies wrote:
> On 2005-11-03 15:40, Pete Becker wrote:
>
>>Niklas Matthies wrote:
>>
>>
>>>Deprecating it won't stop library vendors from providing it for
>>>compatibility reasons
>>
>>Deprecating it would mean that it might be removed in the future.
>>Until that happened, it would continue to be required in a
>>conforming implementation.
>
>
> You're right, of course. It only supports the argument, though.

    The standard excuses for not fixing the gaping security holes
in C and C++ are as follows:

    1. It would break existing code.
    2. It would require a change to the standard.
    3. People would use the deprecated features anyway.
    4. It's not really necessary because l33t programmers don't
 need a safety net.
    5. It's not really necessary because n00b programmers would
 write bad code anyway.
    6. If you need safety, use Java.
    7. It's like smoking.  Millions of crashes a year are a small
 price to pay for personal freedom.

Please give your excuse by number.  Thank you.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: squell@alumina.nl (Marc Schoolderman)
Date: Thu, 3 Nov 2005 19:04:21 GMT
Raw View
John Nagle wrote:

>    The standard excuses for not fixing the gaping security holes
> in C and C++ are as follows:

However, you will probably agree that the gaping security holes are
primarily functions such as sprintf(), scanf(), strcpy()...

Just deprecating gets() won't make C/C++ a safer language.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "Marcus" <yuu@yyhmail.com>
Date: Sat, 5 Nov 2005 09:10:56 CST
Raw View
Marc Schoolderman escreveu:

> John Nagle wrote:
>
> >    The standard excuses for not fixing the gaping security holes
> > in C and C++ are as follows:
>
> However, you will probably agree that the gaping security holes are
> primarily functions such as sprintf(), scanf(), strcpy()...
>
> Just deprecating gets() won't make C/C++ a safer language.
>
> ~Marc.

Well, we have to start somewhere ;-)
I also consider this as a usability improvement for newbies. They
shouldn't be distracted by badly designed functions like gets(), and
should be directed to other functions (such as getline()) right at the
beginning. I know the standard won't enforce the warning message, but
deprecation is the "tool" the standard has to warn that a feature
should not be used in new programs.

If we deprecate gets() in C++0x, maybe it will be removed in C++1x or
in C++2x (I know some people would like to deprecate C++ as a whole
before that ;-) ). Until then, people maintaining C++ sources will most
likely replace gets() for security reasons and new programs with gets()
would be rarer. And, if you __must__ use gets() after that, reimplement
it! :-) It doesn't take more than 20 lines of code. While you're at it,
write a bounds-checked version ;-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: squell@alumina.nl (Marc Schoolderman)
Date: Sat, 5 Nov 2005 23:09:46 GMT
Raw View
Marcus wrote:

> I also consider this as a usability improvement for newbies. They
> shouldn't be distracted by badly designed functions like gets(), and
> should be directed to other functions (such as getline()) right at the
> beginning. I know the standard won't enforce the warning message, but
> deprecation is the "tool" the standard has to warn that a feature
> should not be used in new programs.

While I agree that people should get directed to <string> instead of
<string.h>, I disagree that the Standard is the place to do that.

It simply doesn't work, anyway -- there are lots of things that are
illegal but which do not require a diagnostic - the ODR for example.
"namespace-scope static" and "bool++" are also deprecated, but I don't
get any warning for those.

(In fact, why were those two features deprecated?)

OTOH, my implementation already warns about gets() w/o any help:

/tmp/ccqw7PMm.o(.text+0x1d): In function `main':
: warning: the `gets' function is dangerous and should not be used.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: kst-u@mib.org (Keith Thompson)
Date: Mon, 7 Nov 2005 00:22:58 GMT
Raw View
squell@alumina.nl (Marc Schoolderman) writes:
> John Nagle wrote:
>>    The standard excuses for not fixing the gaping security holes
>> in C and C++ are as follows:
>
> However, you will probably agree that the gaping security holes are
> primarily functions such as sprintf(), scanf(), strcpy()...
>
> Just deprecating gets() won't make C/C++ a safer language.

sprintf(), scanf(), and strcpy() can be used safely in some realistic
circumstances.  gets() cannot.  (It can be used safely only if you
have complete control over what's in stdin -- but even then the
benefit of using gets() rather than fgets() is insignificant.)

I don't think anyone is claiming that deprecating (or removing) gets()
would make it significantly more difficult to write buggy C or C++
code.  But unlike sprintf(), scanf() or strcpy(), gets() is so
uniquely dangerous that, IMHO, the burden of proof should be on those
who want to keep it.

Removing gets() would "break" existing code, but any such code is
already broken.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: charlie.stott@ffei.co.uk (Charlie Stott)
Date: Mon, 7 Nov 2005 15:45:38 GMT
Raw View
Marc Schoolderman wrote:
> ... "bool++" are also deprecated, but I don't
> get any warning for those.
>
> (In fact, why were those two features deprecated?)

What functionality do you expect?

a) <bool> will be inverted
b) <bool> will be incremented (what type is <bool> based on?)?

if a) then use !=, if b) then why are you using <bool>?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Mon, 7 Nov 2005 15:46:28 GMT
Raw View
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnr79t9z52.fsf@nuthaus.mib.org...

> squell@alumina.nl (Marc Schoolderman) writes:
>> John Nagle wrote:
>>>    The standard excuses for not fixing the gaping security holes
>>> in C and C++ are as follows:
>>
>> However, you will probably agree that the gaping security holes are
>> primarily functions such as sprintf(), scanf(), strcpy()...
>>
>> Just deprecating gets() won't make C/C++ a safer language.
>
> sprintf(), scanf(), and strcpy() can be used safely in some realistic
> circumstances.  gets() cannot.  (It can be used safely only if you
> have complete control over what's in stdin -- but even then the
> benefit of using gets() rather than fgets() is insignificant.)
>
> I don't think anyone is claiming that deprecating (or removing) gets()
> would make it significantly more difficult to write buggy C or C++
> code.  But unlike sprintf(), scanf() or strcpy(), gets() is so
> uniquely dangerous that, IMHO, the burden of proof should be on those
> who want to keep it.

Good thing your O is H, because the C committee was acting under
different rules. We followed the quaint, old fashioned practice
of "codifying existing practice." Rather than invent something,
get it standardized, and see if it was any good, we chose to
take what was out in the field and iron out any dialect differences
to make a standard. Along the way, we noticed quite a number of
things that, well, sucked, but we left them in if enough people
(in the room) argued that they were in widespread use. Even by
the mid 1980s the C code base was pretty formidable; users
assured us quite loudly that they didn't want to have to perform
wholesale edits of their existing code even if it was "for their
own good."

> Removing gets() would "break" existing code, but any such code is
> already broken.

That remains your HO, even though you've been given examples where
it is not true.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: clarkcox3@gmail.com ("Clark S. Cox III")
Date: Tue, 8 Nov 2005 05:18:35 GMT
Raw View
On 2005-11-07 10:45:38 -0500, charlie.stott@ffei.co.uk (Charlie Stott) said:

> Marc Schoolderman wrote:
>> ... "bool++" are also deprecated, but I don't get any warning for those.
>>
>> (In fact, why were those two features deprecated?)
>
> What functionality do you expect?
>
> a) <bool> will be inverted
> b) <bool> will be incremented (what type is <bool> based on?)?
>
> if a) then use !=, if b) then why are you using <bool>?

(++b) and (b = true) are equivalent.


--
Clark S. Cox, III
clarkcox3@gmail.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: kst-u@mib.org (Keith Thompson)
Date: Tue, 8 Nov 2005 05:21:14 GMT
Raw View
pjp@dinkumware.com ("P.J. Plauger") writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnr79t9z52.fsf@nuthaus.mib.org...
>> squell@alumina.nl (Marc Schoolderman) writes:
>>> John Nagle wrote:
>>>>    The standard excuses for not fixing the gaping security holes
>>>> in C and C++ are as follows:
>>>
>>> However, you will probably agree that the gaping security holes are
>>> primarily functions such as sprintf(), scanf(), strcpy()...
>>>
>>> Just deprecating gets() won't make C/C++ a safer language.
>>
>> sprintf(), scanf(), and strcpy() can be used safely in some realistic
>> circumstances.  gets() cannot.  (It can be used safely only if you
>> have complete control over what's in stdin -- but even then the
>> benefit of using gets() rather than fgets() is insignificant.)
>>
>> I don't think anyone is claiming that deprecating (or removing) gets()
>> would make it significantly more difficult to write buggy C or C++
>> code.  But unlike sprintf(), scanf() or strcpy(), gets() is so
>> uniquely dangerous that, IMHO, the burden of proof should be on those
>> who want to keep it.
>
> Good thing your O is H, because the C committee was acting under
> different rules. We followed the quaint, old fashioned practice
> of "codifying existing practice." Rather than invent something,
> get it standardized, and see if it was any good, we chose to
> take what was out in the field and iron out any dialect differences
> to make a standard. Along the way, we noticed quite a number of
> things that, well, sucked, but we left them in if enough people
> (in the room) argued that they were in widespread use. Even by
> the mid 1980s the C code base was pretty formidable; users
> assured us quite loudly that they didn't want to have to perform
> wholesale edits of their existing code even if it was "for their
> own good."

I understand the need for codifying existing practice.  My argument is
that gets() is *uniquely* dangerous.  I wonder how big the outcry
would have been if gets() had been dropped from the C89 standard, with
no other changes.

What if the committee had treated gets() the same way they treated
strdup()?  If I recall correctly, strdup() was a very commonly
provided library function, but the C89 standard doesn't provide it.
Many (most?) implementations now provide strdup() as an extension, and
a lot of code still uses it.  Those who are concerned about
portability can easily implement their own dupstr() function.

>> Removing gets() would "break" existing code, but any such code is
>> already broken.
>
> That remains your HO, even though you've been given examples where
> it is not true.

Not really.  I gave a *hypothetical* example of a program being
executed in an environment where there's complete control over what's
going to show up on stdin.  Has anyone ever done this in real life?
Have you ever seen a safe usage of gets()?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "Marcus" <yuu@yyhmail.com>
Date: Mon, 7 Nov 2005 23:22:15 CST
Raw View
Marc Schoolderman escreveu:

> OTOH, my implementation already warns about gets() w/o any help:
>
> /tmp/ccqw7PMm.o(.text+0x1d): In function `main':
> : warning: the `gets' function is dangerous and should not be used.

That's what i call "existing practice of deprecation" of gets(). So the
standards codify existing practice, right? :-D

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: charlie.stott@ffei.co.uk (Charlie Stott)
Date: Wed, 9 Nov 2005 04:32:09 GMT
Raw View
Clark S. Cox III wrote:
> On 2005-11-07 10:45:38 -0500, charlie.stott@ffei.co.uk (Charlie Stott)
> said:
>
>> Marc Schoolderman wrote:
>>
>>> ... "bool++" are also deprecated, but I don't get any warning for those.
>>>
>>> (In fact, why were those two features deprecated?)
>>
>>
>> What functionality do you expect?
>>
>> a) <bool> will be inverted
>> b) <bool> will be incremented (what type is <bool> based on?)?
>>
>> if a) then use !=, if b) then why are you using <bool>?
>
>
> (++b) and (b = true) are equivalent.
>
>

So, why would you need to use (++b), when there is a more suitable
alternative?

What if (<bool> == MAX_INT)?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Wed, 9 Nov 2005 04:32:40 GMT
Raw View
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lny8405fni.fsf@nuthaus.mib.org...

> pjp@dinkumware.com ("P.J. Plauger") writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnr79t9z52.fsf@nuthaus.mib.org...
>>> squell@alumina.nl (Marc Schoolderman) writes:
>>>> John Nagle wrote:
>>>>>    The standard excuses for not fixing the gaping security holes
>>>>> in C and C++ are as follows:
>>>>
>>>> However, you will probably agree that the gaping security holes are
>>>> primarily functions such as sprintf(), scanf(), strcpy()...
>>>>
>>>> Just deprecating gets() won't make C/C++ a safer language.
>>>
>>> sprintf(), scanf(), and strcpy() can be used safely in some realistic
>>> circumstances.  gets() cannot.  (It can be used safely only if you
>>> have complete control over what's in stdin -- but even then the
>>> benefit of using gets() rather than fgets() is insignificant.)
>>>
>>> I don't think anyone is claiming that deprecating (or removing) gets()
>>> would make it significantly more difficult to write buggy C or C++
>>> code.  But unlike sprintf(), scanf() or strcpy(), gets() is so
>>> uniquely dangerous that, IMHO, the burden of proof should be on those
>>> who want to keep it.
>>
>> Good thing your O is H, because the C committee was acting under
>> different rules. We followed the quaint, old fashioned practice
>> of "codifying existing practice." Rather than invent something,
>> get it standardized, and see if it was any good, we chose to
>> take what was out in the field and iron out any dialect differences
>> to make a standard. Along the way, we noticed quite a number of
>> things that, well, sucked, but we left them in if enough people
>> (in the room) argued that they were in widespread use. Even by
>> the mid 1980s the C code base was pretty formidable; users
>> assured us quite loudly that they didn't want to have to perform
>> wholesale edits of their existing code even if it was "for their
>> own good."
>
> I understand the need for codifying existing practice.  My argument is
> that gets() is *uniquely* dangerous.

Each of a couple dozen functions in the Standard C library have their
own unique dangers.

>                                     I wonder how big the outcry
> would have been if gets() had been dropped from the C89 standard, with
> no other changes.

We'll never know. The C committee made several thousand decisions
between 1983 and 1988 and we now live with that fabric.

> What if the committee had treated gets() the same way they treated
> strdup()?

IIRC, strdup wasn't in the base document we began with, while
gets was.

>           If I recall correctly, strdup() was a very commonly
> provided library function, but the C89 standard doesn't provide it.
> Many (most?) implementations now provide strdup() as an extension, and
> a lot of code still uses it.

It's also in Posix, I believe.

>                              Those who are concerned about
> portability can easily implement their own dupstr() function.

Yep. But that wasn't why it didn't make the C Standard.

>>> Removing gets() would "break" existing code, but any such code is
>>> already broken.
>>
>> That remains your HO, even though you've been given examples where
>> it is not true.
>
> Not really.  I gave a *hypothetical* example of a program being
> executed in an environment where there's complete control over what's
> going to show up on stdin.  Has anyone ever done this in real life?

Yes.

> Have you ever seen a safe usage of gets()?

Yes.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "kanze" <kanze@gabi-soft.fr>
Date: Wed, 9 Nov 2005 15:00:07 CST
Raw View
Charlie Stott wrote:
> Clark S. Cox III wrote:
> > On 2005-11-07 10:45:38 -0500, charlie.stott@ffei.co.uk
> > (Charlie Stott) said:

> >> Marc Schoolderman wrote:

> >>> ... "bool++" are also deprecated, but I don't get any warning for those.

> >>> (In fact, why were those two features deprecated?)

> >> What functionality do you expect?

> >> a) <bool> will be inverted
> >> b) <bool> will be incremented (what type is <bool> based on?)?

> >> if a) then use !=, if b) then why are you using <bool>?

> > (++b) and (b = true) are equivalent.

> So, why would you need to use (++b), when there is a more
> suitable alternative?

Some existing code, using int's for bool's, did use b++ or ++b
to set to true.  Don't ask me why, but it did seem to be an in
thing at one time; at least, I've seen it a lot.

> What if (<bool> == MAX_INT)?

Your (pre-standard) code breaks.

One of the most common uses was in option handling.  Something
along the lines of:

    int     oSet = 0 ;

    int main( int argc, char** argv )
    {
        int i = 1 ;
        while ( i < argc && argv[ i ][ 0 ] == '-' ) {
        char * opts = argv[ i ] + 1 ;
        while ( *opts != '\0' ) {
            switch ( *opts ) {
            case 'o' :
                oSet ++ ;
                break ;
            //  ...
            }
            opts ++ ;
        }
        //  ...
    }

I guess the test suites used to validate the program didn't
include a case where the same option was given INT_MAX times.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: squell@alumina.nl (Marc Schoolderman)
Date: Thu, 10 Nov 2005 04:05:15 GMT
Raw View
Charlie Stott wrote:

>>> What functionality do you expect?
>>> a) <bool> will be inverted
>>> b) <bool> will be incremented (what type is <bool> based on?)?
>>> if a) then use !=, if b) then why are you using <bool>?
>> (++b) and (b = true) are equivalent.
> So, why would you need to use (++b), when there is a more suitable
> alternative?

That by itself does not justify deprecation, though.

> What if (<bool> == MAX_INT)?

Not a problem, by definition. The only thing I can think of is that it
causes the following 'surprising' behavior:

bool x; ++x; ++x; --x;    // x == false

Which might wreak havoc in generic functions which were not expecting a
boolean.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: nagle@animats.com (John Nagle)
Date: Thu, 10 Nov 2005 04:05:40 GMT
Raw View
    Actually, "gets" is being deprecated.  It's not in
Java or C#.

    Rather than simply deprecating the bad features
of C++ one at a time, it's being done in bulk.

   John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: kst-u@mib.org (Keith Thompson)
Date: Thu, 10 Nov 2005 04:05:30 GMT
Raw View
pjp@dinkumware.com ("P.J. Plauger") writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lny8405fni.fsf@nuthaus.mib.org...
[...]
>> Have you ever seen a safe usage of gets()?
>
> Yes.

I'd be interested in knowing some of the details (assuming you can
discuss it without releasing confidential information, of course).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: usenet-nospam@nmhq.net (Niklas Matthies)
Date: Thu, 10 Nov 2005 14:57:19 GMT
Raw View
On 2005-11-10 04:05, John Nagle wrote:
> Actually, "gets" is being deprecated.  It's not in Java or C#.

That's a pretty funny comment, because gets() would be necessarily
safe in Java (and in C# unless using 'unsafe'). It would simply throw
an ArrayIndexOutOfBoundsException or equivalent for inputs that exceed
the array size.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: charlie.stott@ffei.co.uk (Charlie Stott)
Date: Thu, 10 Nov 2005 14:57:08 GMT
Raw View
kanze wrote:
> Charlie Stott wrote:
>
>>Clark S. Cox III wrote:
>>
>>>On 2005-11-07 10:45:38 -0500, charlie.stott@ffei.co.uk
>>>(Charlie Stott) said:
>
>
>>>>Marc Schoolderman wrote:
>
>
>>>>>... "bool++" are also deprecated, but I don't get any warning for those.
>
>
>>>>>(In fact, why were those two features deprecated?)
>
>
>>>>What functionality do you expect?
>
>
>>>>a) <bool> will be inverted
>>>>b) <bool> will be incremented (what type is <bool> based on?)?
>
>
>>>>if a) then use !=, if b) then why are you using <bool>?
>
>
>>>(++b) and (b = true) are equivalent.
>
>
>>So, why would you need to use (++b), when there is a more
>>suitable alternative?
>
>
> Some existing code, using int's for bool's, did use b++ or ++b
> to set to true.  Don't ask me why, but it did seem to be an in
> thing at one time; at least, I've seen it a lot.
>
>
>>What if (<bool> == MAX_INT)?
>
>
> Your (pre-standard) code breaks.
>

I think the point has been made...

We have answered the question (why it was deprecated).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Thu, 10 Nov 2005 14:59:07 GMT
Raw View
"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln3bm51ly7.fsf@nuthaus.mib.org...

> pjp@dinkumware.com ("P.J. Plauger") writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lny8405fni.fsf@nuthaus.mib.org...
> [...]
>>> Have you ever seen a safe usage of gets()?
>>
>> Yes.
>
> I'd be interested in knowing some of the details (assuming you can
> discuss it without releasing confidential information, of course).

The cases I've seen have been just as you described -- a
single program writes a file and reads it back, full
secure in the knowledge that all line lengths are bounded.
Before you rush to raise the specter of disk hiccups, I'll
report that at least one of those cases involved a "memory"
file. There the sort of failures are akin to the ones that
corrupt memory images in general, and hardly more likely than
a rewritten function call.

Having answered your question, I admit that I never use gets
myself, and I advocate that others avoid it as well. But
that advice is separable from the issue of whether gets should
have made it into the C Standard in the first place. And *that*
is completely separable from the issue of whether it should
now be removed. The latter two involve balancings that you
tend to dismiss out of hand, but whice lie at the center of
responsible standards development.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]