warning C4267 and warning C4996 - c++

First of all, please don't double space code and please do indent it.

B. Williams wrote:
> I am receiving two warnings in my code and can't figure out why. Will
> someone look at this and tell me what I have done wrong?
>
> #include <iostream>
>
> using std::cout;
>
> #include <string>
>
> using std::string;
>
> class PPG{
>
> public:
>
> PPG(char *a, char b, int c)
>
> { dresscolor =b;
>
> power = c;
>
> setname(a);}//end constructor 1
>
> PPG()
>
> { setname("Ms. Bellum");
>
> dresscolor ='p';
>
> power = 0;
>
> }//end default constructor
>
> char * getname()const {return name;}
>
>
> void setname(char *a){
>
> int l =strlen(a);

Here's your problem. (Does your compiler not give you line numbers to
go along with its warnings?) strlen returns a size_t (some
implementation defined unsigned integral type) and you're storing that
in an int. Simply declaring l to be of type size_t should resolve this.
Or don't declare it at all-- see below.

>
> name = new char[l+1];
>
> strcpy(name,a);

Apparently your compiler doesn't like you using strcpy. A google search
for: strcpy deprecated, turns up various MSFT links that suggest that
_they_ have deprecated this function in favor of something called
strcpy_s. Use that instead it if you like, but bear in mind that it's
not portable.

>
> name[l] = '\0';

There's no need to do this. strcpy will copy the null terminator of its
second argument. In fact this whole function can be simplified to a
single line:

void setname( char* a)
{
strcpy( name = new char[ strlen(a) + 1], a);
}


But, this all misses a bigger issue, namely, why aren't you using
std::string? As it stands your code already has memory leaks-- no
destructor to delete[] the memory allocated to name, not to mention the
same missing delete[] in the case of successive calls to setname.

Strangely you've even included the <string> header, but you haven't used
it for anything! I would strongly suggest rewriting this to use
std::string in place of char*.

Mark

"B. Williams" <willdrama@hotmail.com> wrote in message
news:zu60h.66520$Yh7.53607@newsfe21.lga...
>I am receiving two warnings in my code and can't figure out why. Will
>someone look at this and tell me what I have done wrong?
>
> #include <iostream>
>
> using std::cout;
>
> #include <string>
>
> using std::string;
>
> class PPG{
>
> public:
>
> PPG(char *a, char b, int c)
>
> { dresscolor =b;
>
> power = c;
>
> setname(a);}//end constructor 1
>
> PPG()
>
> { setname("Ms. Bellum");
>
> dresscolor ='p';
>
> power = 0;
>
> }//end default constructor
>
> char * getname()const {return name;}
>
>
> void setname(char *a){
>
> int l =strlen(a);
>
> name = new char[l+1];
>
> strcpy(name,a);
>
> name[l] = '\0';
>
> }//end setname
>
> int getpower() const{return power;}
>
> void setpower(int z){power = z;}
>
> char getdresscolor() const{return dresscolor;}
>
> void setdresscolor(char v){dresscolor=v;}
>
> void print() const
>
> { cout <<name << " likes to wear ";
>
> switch (dresscolor){
>
> case 'g': case 'G':
>
> cout <<"green dresses. She uses her "; break;
>
> case 'b':case 'B':
>
> cout <<"blue dresses. She uses her ";break;
>
> case 'p': case 'P':
>
> cout <<"pink dresses. She uses her ";
>
> }//end switch
>
> if (power == 1)
>
> cout << "ice breath to defeat her enemies.\n";
>
> else if (power ==2)
>
> cout << "ability to talk to squirrels to confuse evil villians.\n";
>
> else if (power ==3)
>
> cout <<"bad attitude to stop evil doers.\n";
>
> else
>
> cout <<"girl power to rule the world.\n";
>
> }//end print
>
> bool operator==(PPG &ppg)
>
> { return (strcmp(name, ppg.name)==0); }
>
> private:
>
> char * name;
>
> char dresscolor; //g-reen, b-lue, p-pink
>
> int power; //1-ice breath, 2- squirrel speak, 3-bad attitude
>
> }; //end class
>
> #include "ppg.h"
>
> #include <iostream>
>
> int main()
>
> {
>
> PPG girl1("Bubbles", 'b', 2);
>
> girl1.print();
>
> PPG badgirl("Princess",'g', 4);
>
> badgirl.print();
>
>
> return 0;
>
> }//end main
>
> These are the warnings I am getting.
>
> warning C4267: 'initializing' : conversion from 'size_t' to 'int',
> possible loss of data

size_t is a type that strlen returns. So just use that to store your
reutrned variable
size_t l =strlen(a);

> warning C4996: 'strcpy' was declared deprecated

This is a Microsoft warning. strcpy will copy a c-style string into a
buffer without ensuring there is enough room in the buffer. So in .net 2005
on they (microsoft) decided that strcpy was depreciated and want you to use
strcpy_s which gets passed the size of the buffer as the 2nd parm.

This can cause problems. Someone asked me to work on some code they wrote
in vc .net 2005, and I have .net 2003, and they used strcpy_s isntead of
strcpy. Of course, I dont' have strcpy_s in .2003 so am going to have to
define around it, back to using strcpy. Pain in the neck, although
microsoft does have a point, strcpy can cause buffer overruns.

>
> I am also getting this.
>
> program files\microsoft visual studio 8\vc\include\string.h(73) : see
> declaration of 'strcpy'

On Thu, 26 Oct 2006 19:19:36 GMT, Mark P
<usenet@fall2005REMOVE.fastmailCAPS.fm> wrote:
>> strcpy(name,a);
>
>Apparently your compiler doesn't like you using strcpy. A google search
>for: strcpy deprecated, turns up various MSFT links that suggest that
>_they_ have deprecated this function in favor of something called
>strcpy_s. Use that instead it if you like, but bear in mind that it's
>not portable.

The C Standards committee is working on a series of new library
functions that are more secure. They have published the following
draft document:

ISO/IEC JTC1 SC22 WG14 N1135
Date: 2005-09-06
Reference number of document: ISO/IEC TR 24731
Committee identification: ISO/IEC JTC1 SC22 WG14

Information Technology —
Programming languages, their environments and system software
interfaces —
Specification for Safer, More Secure C Library Functions —

It is a draft document so far, but I've seen a book published on it
already! MS appears to have decided that will deprecate the old
less-secure functions. I'm not sure that the draft document
recommends that measure. Rather, it writes about merging the two
libraries. So MS may be too many steps ahead of the curve.

I've recently bought the new VS, and it is a pain to have these
warnings. The following listing from the draft document gives a
flavor of what might be in store in the future (present for VS).

6.7.1.3 The strcpy_s function
Synopsis
1 #define _ _STDC_WANT_LIB_EXT1_ _ 1
#include <string.h>
errno_t strcpy_s(char * restrict s1, rsize_t s1max, const char *
restrict s2);

Runtime-constraints
2 Neither s1 nor s2 shall be a null pointer. s1max shall not be
greater than RSIZE_MAX. s1max shall not equal zero. s1max shall be
greater than strnlen_s(s2, s1max).
3 If there is a runtime-constraint violation, then if s1 is not a null
pointer and s1max is greater than zero and not greater than RSIZE_MAX,
then strcpy_s sets s1[0] to the null character.

Description
4 The strcpy_s function copies the string pointed to by s2 (including
the terminating null character) into the array pointed to by s1.
5 All elements following the terminating null character (if any)
written by strcpy_s in the array of s1max characters pointed to by s1
take unspecified values when strcpy_s returns.(33)
6 If copying takes place between objects that overlap, the objects
take on unspecified values.

Returns
7 The strcpy_s function returns zero(34) if there was no
runtime-constraint violation. Otherwise, a non-zero value is
returned.

Best wishes,

Bob

Jim Langston wrote:
> This can cause problems. Someone asked me to work on some code they wrote
> in vc .net 2005, and I have .net 2003, and they used strcpy_s isntead of
> strcpy. Of course, I dont' have strcpy_s in .2003 so am going to have to
> define around it, back to using strcpy.

Don't do that. People may have written code that relies on
strcpy_s not causing a buffer overflow. Instead, implement
it yourself (it's not tricky).

Old Wolf said:

> Jim Langston wrote:
>> This can cause problems. Someone asked me to work on some code they
>> wrote in vc .net 2005, and I have .net 2003, and they used strcpy_s
>> isntead of
>> strcpy. Of course, I dont' have strcpy_s in .2003 so am going to have to
>> define around it, back to using strcpy.
>
> Don't do that. People may have written code that relies on
> strcpy_s not causing a buffer overflow. Instead, implement
> it yourself (it's not tricky).

Better still, fix the broken assumption, and then use strcpy.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Richard Heathfield wrote:
> Old Wolf said:
>
> > Jim Langston wrote:
> >> This can cause problems. Someone asked me to work on some code they
> >> wrote in vc .net 2005, and I have .net 2003, and they used strcpy_s
> >> isntead of
> >> strcpy. Of course, I dont' have strcpy_s in .2003 so am going to have to
> >> define around it, back to using strcpy.
> >
> > Don't do that. People may have written code that relies on
> > strcpy_s not causing a buffer overflow. Instead, implement
> > it yourself (it's not tricky).
>
> Better still, fix the broken assumption, and then use strcpy.

Or strncpy.

Regards,
Bart.

Bart said:

> Richard Heathfield wrote:
>> Old Wolf said:
>>
>> > Jim Langston wrote:
>> >> This can cause problems. Someone asked me to work on some code they
>> >> wrote in vc .net 2005, and I have .net 2003, and they used strcpy_s
>> >> isntead of
>> >> strcpy. Of course, I dont' have strcpy_s in .2003 so am going to have
>> >> to define around it, back to using strcpy.
>> >
>> > Don't do that. People may have written code that relies on
>> > strcpy_s not causing a buffer overflow. Instead, implement
>> > it yourself (it's not tricky).
>>
>> Better still, fix the broken assumption, and then use strcpy.
>
> Or strncpy.

If you like throwing away data, that is.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

In article <P4WdnV94PqdCRNjYnZ2dnUVZ8sidnZ2d@bt.com>,
Richard Heathfield <invalid@invalid.invalid> wrote:
>Bart said:
>> Richard Heathfield wrote:
>>> Old Wolf said:
>>> > Jim Langston wrote:
>>> >> This can cause problems. Someone asked me to work on some code they
>>> >> wrote in vc .net 2005, and I have .net 2003, and they used strcpy_s
>>> >> isntead of
>>> >> strcpy. Of course, I dont' have strcpy_s in .2003 so am going to have
>>> >> to define around it, back to using strcpy.
>>> >
>>> > Don't do that. People may have written code that relies on
>>> > strcpy_s not causing a buffer overflow. Instead, implement
>>> > it yourself (it's not tricky).
>>>
>>> Better still, fix the broken assumption, and then use strcpy.
>>
>> Or strncpy.
>
>If you like throwing away data, that is.

He probably meant with knowledge of the n, but of course that has
its own tradeoffs, as does the original argument of overwritting data.
INO, strcpy is a meaty function for discussion, the likes of which
I like to get into when I teach C++ or C, since it allows one to
touch on a number of issues of design, use, etc. And then if that
has those issues, be wary of your more involved functions and other
abstractions etc. which becomes a cornerstone of concern.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

"Greg Comeau" <comeau@panix.com> wrote in message
news:ei4s3l$66l$1@panix3.panix.com...
> In article <P4WdnV94PqdCRNjYnZ2dnUVZ8sidnZ2d@bt.com>,
> Richard Heathfield <invalid@invalid.invalid> wrote:
>>Bart said:
>>> Richard Heathfield wrote:
>>>> Old Wolf said:
>>>> > Jim Langston wrote:
>>>> >> This can cause problems. Someone asked me to work on some code they
>>>> >> wrote in vc .net 2005, and I have .net 2003, and they used strcpy_s
>>>> >> isntead of
>>>> >> strcpy. Of course, I dont' have strcpy_s in .2003 so am going to
>>>> >> have
>>>> >> to define around it, back to using strcpy.
>>>> >
>>>> > Don't do that. People may have written code that relies on
>>>> > strcpy_s not causing a buffer overflow. Instead, implement
>>>> > it yourself (it's not tricky).
>>>>
>>>> Better still, fix the broken assumption, and then use strcpy.
>>>
>>> Or strncpy.
>>
>>If you like throwing away data, that is.
>
> He probably meant with knowledge of the n, but of course that has
> its own tradeoffs, as does the original argument of overwritting data.
> INO, strcpy is a meaty function for discussion, the likes of which
> I like to get into when I teach C++ or C, since it allows one to
> touch on a number of issues of design, use, etc. And then if that
> has those issues, be wary of your more involved functions and other
> abstractions etc. which becomes a cornerstone of concern.

I was ensured by the original designer of the program that he's not
overflowing the buffer anywhere, and as I'm going through the code I see
that he does have a sufficient sized buffer in all cases, so I'm just
wrapping strcpy inside a function strcpy_s at this point, but I will be
converting them to std::string in the near future to get rid of all doubt
anyway.

I had thought about using strncpy instead of strcpy, but was thinking, if
strncpy could be used instead of strcpy_s, why did microsoft even depreciate
strcpy for strcpy_s when they could of depreciated it for strncpy?