Re: memcpy_s
SourceForge CVS has been flaky lately, and it looks like the CVS web viewer
has not been updated (I believe it runs off a mirror instead of the live CVS
server).
To fix it manually, add the following to misc.h at line 119:
#if (!__STDC_WANT_SECURE_LIB__)
inline void memcpy_s(void *dest, size_t sizeInBytes, const void *src, size_t
count)
{
if (count > sizeInBytes)
throw InvalidArgument("memcpy_s: buffer overflow");
memcpy(dest, src, count);
}
inline void memmove_s(void *dest, size_t sizeInBytes, const void *src,
size_t count)
{
if (count > sizeInBytes)
throw InvalidArgument("memmove_s: buffer overflow");
memmove(dest, src, count);
}
#endif
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Wednesday, April 12, 2006 11:36 AM
Subject: Re: memcpy_s
Hi,
I also stumbled on memcpy_s in VC7.1, but the CVS access is apparently
shut now and I can't login which was possible before, while CVS of other
projects at Sourceforge are working for me. Besides the web-based CVS
viewer suggests it has not had the said fix yet.
http://cvs.sourceforge.net/viewcvs.py/cryptopp/c5/?sortby=date#dirlist
Can anyone browsing here examine this?
-- Ken
On Fri, 7 Apr 2006 21:08:24 -0700
"Wei Dai" <[EMAIL PROTECTED]> wrote:
Adding these #defines in config.h is a not good idea because it would
also
affect code that use Crypto++. But the problem has already been fixed.
Check
the latest code in CVS.
- Original Message -
From: "Peter Kolbus" <[EMAIL PROTECTED]>
To:
Sent: Friday, April 07, 2006 2:30 PM
Subject: RE: memcpy_s
> Actually, the best way to handle this mess for crossplatform
> compatibility
> is to revert to strcpy() in the cryptopp sources, then, in config.h,
> add
> the
> following line:
>
> #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1
>
> This will have the CRT automatically use the secure versions and pass
> the
> length argument. If for some reason this doesn't work, then the next
> best
> is to ignore the compiler warning with
>
> #define _CRT_SECURE_NO_DEPRECATE
>
> Peter Kolbus
>
> -Original Message-
> From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 07, 2006 2:41 PM
> To: cryptopp-list@eskimo.com
> Subject: Re: memcpy_s
>
> Marko Kaiser:
>> That should be surrounded by preprocessor directives like #if _MSCVER
>> >
>> bla #else #endif.
>>
>
> In CVS sources also?
>
>> -Original Message-
>> From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED]
>> Sent: Friday, April 07, 2006 3:46 PM
>> To: cryptopp-list@eskimo.com
>> Subject: Re: memcpy_s
>>
>> Petri Simolin ?:
>>> On the latest CVS version I see that cryptopp is using memcpy_s on
>>> some occasions instead of memcpy.
>>>
>>> Does this mean VS6 is unsupported on future versions of CryptoPP?
>> g++ (GCC) 3.4.5 (mingw special) also usupported?
>>
>>
>>
>>
>
>
Re: memcpy_s
Hi, I also stumbled on memcpy_s in VC7.1, but the CVS access is apparently shut now and I can't login which was possible before, while CVS of other projects at Sourceforge are working for me. Besides the web-based CVS viewer suggests it has not had the said fix yet. http://cvs.sourceforge.net/viewcvs.py/cryptopp/c5/?sortby=date#dirlist Can anyone browsing here examine this? -- Ken On Fri, 7 Apr 2006 21:08:24 -0700 "Wei Dai" <[EMAIL PROTECTED]> wrote: > Adding these #defines in config.h is a not good idea because it would also > affect code that use Crypto++. But the problem has already been fixed. Check > the latest code in CVS. > > - Original Message - > From: "Peter Kolbus" <[EMAIL PROTECTED]> > To: > Sent: Friday, April 07, 2006 2:30 PM > Subject: RE: memcpy_s > > > > Actually, the best way to handle this mess for crossplatform compatibility > > is to revert to strcpy() in the cryptopp sources, then, in config.h, add > > the > > following line: > > > > #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1 > > > > This will have the CRT automatically use the secure versions and pass the > > length argument. If for some reason this doesn't work, then the next best > > is to ignore the compiler warning with > > > > #define _CRT_SECURE_NO_DEPRECATE > > > > Peter Kolbus > > > > -----Original Message- > > From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] > > Sent: Friday, April 07, 2006 2:41 PM > > To: cryptopp-list@eskimo.com > > Subject: Re: memcpy_s > > > > Marko Kaiser: > >> That should be surrounded by preprocessor directives like #if _MSCVER > > >> bla #else #endif. > >> > > > > In CVS sources also? > > > >> -Original Message- > >> From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] > >> Sent: Friday, April 07, 2006 3:46 PM > >> To: cryptopp-list@eskimo.com > >> Subject: Re: memcpy_s > >> > >> Petri Simolin ?: > >>> On the latest CVS version I see that cryptopp is using memcpy_s on > >>> some occasions instead of memcpy. > >>> > >>> Does this mean VS6 is unsupported on future versions of CryptoPP? > >> g++ (GCC) 3.4.5 (mingw special) also usupported? > >> > >> > >> > >> > > > > > >
RE: memcpy_s
Unsubscribe
Re: memcpy_s
Adding these #defines in config.h is a not good idea because it would also affect code that use Crypto++. But the problem has already been fixed. Check the latest code in CVS. - Original Message - From: "Peter Kolbus" <[EMAIL PROTECTED]> To: Sent: Friday, April 07, 2006 2:30 PM Subject: RE: memcpy_s Actually, the best way to handle this mess for crossplatform compatibility is to revert to strcpy() in the cryptopp sources, then, in config.h, add the following line: #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1 This will have the CRT automatically use the secure versions and pass the length argument. If for some reason this doesn't work, then the next best is to ignore the compiler warning with #define _CRT_SECURE_NO_DEPRECATE Peter Kolbus -Original Message- From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 2:41 PM To: cryptopp-list@eskimo.com Subject: Re: memcpy_s Marko Kaiser: That should be surrounded by preprocessor directives like #if _MSCVER > bla #else #endif. In CVS sources also? -Original Message- From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 3:46 PM To: cryptopp-list@eskimo.com Subject: Re: memcpy_s Petri Simolin ?: On the latest CVS version I see that cryptopp is using memcpy_s on some occasions instead of memcpy. Does this mean VS6 is unsupported on future versions of CryptoPP? g++ (GCC) 3.4.5 (mingw special) also usupported?
RE: memcpy_s
Actually, the best way to handle this mess for crossplatform compatibility is to revert to strcpy() in the cryptopp sources, then, in config.h, add the following line: #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1 This will have the CRT automatically use the secure versions and pass the length argument. If for some reason this doesn't work, then the next best is to ignore the compiler warning with #define _CRT_SECURE_NO_DEPRECATE Peter Kolbus -Original Message- From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 2:41 PM To: cryptopp-list@eskimo.com Subject: Re: memcpy_s Marko Kaiser: > That should be surrounded by preprocessor directives like #if _MSCVER > > bla #else #endif. > In CVS sources also? > -Original Message- > From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] > Sent: Friday, April 07, 2006 3:46 PM > To: cryptopp-list@eskimo.com > Subject: Re: memcpy_s > > Petri Simolin ?: >> On the latest CVS version I see that cryptopp is using memcpy_s on >> some occasions instead of memcpy. >> >> Does this mean VS6 is unsupported on future versions of CryptoPP? > g++ (GCC) 3.4.5 (mingw special) also usupported? > > > >
Re: memcpy_s
Marko Kaiser: That should be surrounded by preprocessor directives like #if _MSCVER > bla #else #endif. In CVS sources also? -Original Message- From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 3:46 PM To: cryptopp-list@eskimo.com Subject: Re: memcpy_s Petri Simolin ?: On the latest CVS version I see that cryptopp is using memcpy_s on some occasions instead of memcpy. Does this mean VS6 is unsupported on future versions of CryptoPP? g++ (GCC) 3.4.5 (mingw special) also usupported?
RE: memcpy_s
That should be surrounded by preprocessor directives like #if _MSCVER > bla #else #endif. -Original Message- From: Alexander N. Zamaraev [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 3:46 PM To: cryptopp-list@eskimo.com Subject: Re: memcpy_s Petri Simolin ?: > On the latest CVS version I see that cryptopp is using memcpy_s on > some occasions instead of memcpy. > > Does this mean VS6 is unsupported on future versions of CryptoPP? g++ (GCC) 3.4.5 (mingw special) also usupported?
Re: memcpy_s
Petri Simolin ?: On the latest CVS version I see that cryptopp is using memcpy_s on some occasions instead of memcpy. Does this mean VS6 is unsupported on future versions of CryptoPP? g++ (GCC) 3.4.5 (mingw special) also usupported?
