On Mon, 17 Sep 2001, Pete Becker wrote:

> John Nagle wrote:
> >
> > Stuart Golodetz wrote:
> > >
> > > Apart from which, the functions are not
> > > inherently unsafe, they are only unsafe if they are used wrongly.
> >
> > Wrong.  Click on this link to bring up all web pages which
> > mention "strcpy" and "buffer overflow".
>
> Perhaps you could save some of us some reading by pointing out which of
> these pages shows examples of buffer overflow occuring when strcpy is
> used correctly.
>
>

Perosnally I don't think we should be getting rid of these string
functions since, as Bjarne stated on his FAQ, properly written C code is
C++.  If we deprecate these functions, this will no longer hold.  In fact
I see these functions as very useful.  Have you ever needed to convert an
int to its equivalent string?  If so, I am sure you wish you had an itoa
function.  Well an easy way to write itoa is as follows:

string itoa(int x)
{
    // converts an integer to a string.
    char s[80];

    sprintf(s,"%i",x);

    return string(s);

}


As you can see I used sprintf, which is one of the functions you say
should be deprecated.  I don't know how many times I need to be able to
convert an int to its equivalent string.  Personally I think itoa should
be added to string.h.

--
;=====================================;
; Mike Coon                           ;
; email: mcoon@cs.ucr.edu             ;
; web: http://www.cs.ucr.edu/~mcoon   ;
; Computer Science Graduate           ;
; University of California, Riverside ;
;=====================================;

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <Pine.LNX.4.30.0109201440410.26252-100000@hill.cs.ucr.edu>,
Michael Carl Coon <mcoon@cs.ucr.edu> writes
>Perosnally I don't think we should be getting rid of these string
>functions since, as Bjarne stated on his FAQ, properly written C code is
>C++.

However that assertion is not entirely true:

void foo(int * restrict, int * restrict);

is not only not C++ but AFAIK there is no way to represent the
information that declaration includes in a valid C++ declaration.


Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"John Nagle" <nagle@animats.com> wrote in message
news:3B8D141D.9B362BE3@animats.com...
>     All the old string functions that are unsafe (sprintf, strcpy)
> should be moved to deprecated include files.  In fact, moving them to
> namespace "deprecated" might be a good idea.

A couple of issues with this which I can think of: firstly, the need to work
with obsolete code is still very much prevalent, and old string functions
are helpful for manipulating C-style strings (and some functionality as
Stephen Howe pointed out is just not available except by using such
functions), secondly you just *know* somebody will come along and type this:

using namespace deprecated;

I would say such a step is virtually guaranteed among those who have been
happily using the old string functions for eons, in which case it was a
wasted effort to move all the functions into the deprecated namespace. This
is one of those things which might well be a good idea in theory but is too
impractical to actually do IMHO. Apart from which, the functions are not
inherently unsafe, they are only unsafe if they are used wrongly; TBH it's
never struck me as a major problem that these functions are still present,
though I appreciate your point that in the wrong hands they are not
particularly safe. Frankly I don't think it's going to happen though,
changing it would just break too much code, and it's not worth the hassle.

FWIW,

Stuart.

<snip>


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Stuart Golodetz wrote:
>
> "John Nagle" <nagle@animats.com> wrote in message
> news:3B8D141D.9B362BE3@animats.com...
> >     All the old string functions that are unsafe (sprintf, strcpy)
> > should be moved to deprecated include files.  In fact, moving them to
> > namespace "deprecated" might be a good idea.
>
> A couple of issues with this which I can think of: firstly, the need to work
> with obsolete code is still very much prevalent, and old string functions
> are helpful for manipulating C-style strings (and some functionality as
> Stephen Howe pointed out is just not available except by using such
> functions), secondly you just *know* somebody will come along and type this:
>
> using namespace deprecated;

    That's OK.  Somebody has to make the decision to do that.

> Apart from which, the functions are not
> inherently unsafe, they are only unsafe if they are used wrongly.

Wrong.  Click on this link to bring up all web pages which
mention "strcpy" and "buffer overflow".

    http://www.google.com/search?q=strcpy+%22buffer+overflow%22

Top items:
 "rdist" buffer overflow exploit
 RSA Labs: "especially vulnerable"
 Buffer overflow in delivermail
 Samba remote buffer overflow
 [SECURITY] Buffer overflow in nnrpd
 Buffer overflow in php.cgi
 wu-ftpd potential buffer overflow
 linux-kernel unexecutable stack buffer overflow exploits
 cannaserver remote buffer overflow
 DeleGate multiple buffer overflow
 mSQL buffer overflow advisory
 ...

Now if that's not enough to indicate this ia a very bad feature
to have in the language, I don't know what is.

     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.research.att.com/~austern/csc/faq.html                ]

John Nagle wrote:
>
> Stuart Golodetz wrote:
> >
> > Apart from which, the functions are not
> > inherently unsafe, they are only unsafe if they are used wrongly.
>
> Wrong.  Click on this link to bring up all web pages which
> mention "strcpy" and "buffer overflow".

Perhaps you could save some of us some reading by pointing out which of
these pages shows examples of buffer overflow occuring when strcpy is
used correctly.

--
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.research.att.com/~austern/csc/faq.html                ]

    All the old string functions that are unsafe (sprintf, strcpy)
should be moved to deprecated include files.  In fact, moving them to
namespace "deprecated" might be a good idea.

    In fact, if a deprecated module is pulled in during link, it
would be desirable to have a marker in the executable, like a
well-defined ID string, that can be found in executables by
appropriate tools.  This may be beyond the scope of the
standards process, though.

    What else needs to come out?

     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.research.att.com/~austern/csc/faq.html                ]

John Nagle wrote:
>
>     All the old string functions that are unsafe (sprintf, strcpy)
> should be moved to deprecated include files.  In fact, moving them to
> namespace "deprecated" might be a good idea.
>
>     In fact, if a deprecated module is pulled in during link, it
> would be desirable to have a marker in the executable, like a
> well-defined ID string, that can be found in executables by
> appropriate tools.  This may be beyond the scope of the
> standards process, though.
>
>     What else needs to come out?

I would not do that...  Not now.  C++ has the aim of being C compatible
_and_ more importantly not "leaving space below" for anything else but
assembler.  Now removing strcpy as "unsafe" would then also remove
memcpy as "unsafe"... and everything else using pointers...  That is not
feasible.  I also guess "this means war" as far as C compatibility is
concerned.  I am afraid that the amount of code "out there" (in the
X-Files :-) basically makes it impossible to get rid of those
functions.  Library and compiler vendor will have to supply them anyways
for decades to come. :-(

A

---
[ 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.research.att.com/~austern/csc/faq.html                ]

>     All the old string functions that are unsafe (sprintf, strcpy)
> should be moved to deprecated include files.  In fact, moving them to
> namespace "deprecated" might be a good idea.

I wouldn't be too sure about the latter suggestion, they're sometimes
needed for interaction with C code. Sometimes it is just too
inefficient or cumbersome to convert the C style strings to C++
strings, manipulate them, and convert them back again.

>     What else needs to come out?

What really should be deprecated are the C date routines. They are
horrible. Replacing them with a well-designed time class and then
marking them as deprecated would make the standard library easier to
use and easier to comprehend. And perhaps also smaller.

--
Ole Laursen
http://sunsite.dk/olau/

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Attila Feher wrote:
...
> assembler.  Now removing strcpy as "unsafe" would then also remove
> memcpy as "unsafe"... and everything else using pointers...  That is not

Pointers aren't the only safety issue. If you removed pointers, C++
wouldn't be C-like anymore. The complaint about strcpy() is due to the
fact that is lacks a safty feature which is shared by both memcpy() and
strncpy(): a user-imposed upper limit on the amount of memory that it
can access.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Russell Kuyper Jr." wrote:
>
> Attila Feher wrote:
> ...
> > assembler.  Now removing strcpy as "unsafe" would then also remove
> > memcpy as "unsafe"... and everything else using pointers...  That is not
>
> Pointers aren't the only safety issue. If you removed pointers, C++
> wouldn't be C-like anymore. The complaint about strcpy() is due to the
> fact that is lacks a safty feature which is shared by both memcpy() and
> strncpy(): a user-imposed upper limit on the amount of memory that it
> can access.

I guess there is a safety, user defined for it.  You (one, programmer,
user) passes _only_ zero terminated strings to it.  I mean what is safer
in trusting someone to calculate the n in strncpy or the length for
memcpy than trusting the same programmer to pass _only_ a zero
terminated string to strcpy?

I mean why do we trust John Doe not making this mistake:

static char buffer[BUFFSIZE];

CALLBACK yourBuffer( const char *buff, size_t len) {
   memcpy( buffer, buff, len, 1);

   // Instead of
   if (len>BUFFSIZE) {
       throw out_of_mind_error;
   }

   // or
   memcpy( buffer, buff, min(len,BUFFSIZE), 1);
}

than making this:

static char sstring[STRLEN+1];

// str is guarantied to be zero terminated
CALLBACK yourString( const char *str) {
  strcpy( sstring, str);
}

???

What makes this error more likely than a memcpy or strncpy error?

BTW the guy uses strncpy:

char buf1[5];

strncpy( buf1, "1234567890", 5);

char buf2[100];

strncpy( buf2, buf1, 100);

So?  _Same_ error with strncpy than strcpy: overrun.  Why is it safer?

Attila

---
[ 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.research.att.com/~austern/csc/faq.html                ]

John Nagle <nagle@animats.com> wrote in message
news:3B8D141D.9B362BE3@animats.com...
>     All the old string functions that are unsafe (sprintf, strcpy)
> should be moved to deprecated include files.  In fact, moving them to
> namespace "deprecated" might be a good idea.

They are still of use so I don't see why they should be regarded as
deprecated.
Some of their functionality is just not present in equivalent C++ library
functions and until it is, I will carry on using them (safely I hope).

Stephen Howe



---
[ 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.research.att.com/~austern/csc/faq.html                ]