Question about Deprecated Functions
Jack
for that little part be 16-bit?
Say
strcpy (hello, hello2)
mov ax, offser hello
....
if I use cout << hello
then
mov eax, offset hello
Thanks
Jack
William DePalo [MVP VC++]
news:OanE28VI...@TK2MSFTNGP10.phx.gbl...
> If I still make use of functions like strcpy, would the final machine code
> for that little part be 16-bit?
No. It simply means that the usage of the function is discouraged and at
some time in the future it _may_ be removed from the library.
Regards,
Will
Sandeep
removing functions like strcpy would mean giving up the compatibility
with C , even though you did mention it as a _may_ , i am still
interested in knowing _why_ are these methods deprecated in vc8 - Is
it something to to with preference of "string" over "char *" in c++.
does this also mean that strcpy is deprecated in the c++ standard too ?
if not , is vc8 moving further away from ISO c++ ?
Frank Hickman [MVP]
news:1138212935.0...@g49g2000cwa.googlegroups.com...
AFAIK, the reason this particular function is "depreciated" in VC8 is that a
replacement function was written that does buffer checking, for security.
--
============
Frank Hickman
Microsoft MVP
NobleSoft, Inc.
============
Replace the _nosp@m_ with @ to reply.
Igor Tandetnik
> William DePalo [MVP VC++] wrote:
>> "Jack" <j...@knight.com> wrote in message
>> news:OanE28VI...@TK2MSFTNGP10.phx.gbl...
>>> If I still make use of functions like strcpy, would the final
>>> machine code for that little part be 16-bit?
>>
>> No. It simply means that the usage of the function is discouraged
>> and at some time in the future it _may_ be removed from the library.
>
> removing functions like strcpy would mean giving up the compatibility
> with C , even though you did mention it as a _may_ , i am still
> interested in knowing _why_ are these methods deprecated in vc8
They are not really deprecated, in the sense that there are no plans to
remove them any time soon. It's just that #pragma deprecated is the only
available mechanism at this time to produce a warning every time a
function is used, hence a somewhat misleading message.
As to the reason for the warning, see
http://msdn2.microsoft.com/en-US/library/8ef0s5kh.aspx
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
William DePalo [MVP VC++]
news:1138212935.0...@g49g2000cwa.googlegroups.com...
> with C , even though you did mention it as a _may_ , i am still
> interested in knowing _why_ are these methods deprecated in vc8
Because they are infamous causes of buffer overrun errors and because buffer
overruns are the prime means that malware authors use to do evil.
> Is it something to to with preference of "string" over "char *" in c++.
Certainly in C++ the std::string class is preferred over the ancient C
runtime though moving to C++ idioms was not the overarching goal of the
deprecation.
> does this also mean that strcpy is deprecated in the c++ standard too ?
No.
> if not , is vc8 moving further away from ISO c++ ?
As I see it, no.
MS would rather that you use the so-called _safe_ variants of these
functions:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx
but nothing is removed yet.
Just by the way, not everyone is convinced that this is a good idea.
Regards,
Will
red floyd
Just out of curiosity, what exactly does strcpy_s() offer that strncpy()
doesn't (other than parameter ordering)?
Igor Tandetnik
> Just out of curiosity, what exactly does strcpy_s() offer that
> strncpy() doesn't (other than parameter ordering)?
strcpy_s is not analogous to strncpy - strncpy_s is. If a buffer passed
to strcpy_s proves to be too small, an error is reported and the
destination is untouched. Thus it cannot be used as strncpy replacement.
strncpy does not guarantee the resulting string is NUL-terminated.
That's likely to create a buffer overrun further down in the program.
strncpy_s guarantees the result is NUL-terminated.
strcpy_s and strncpy_s report error conditions via errno_t return value
or user-installed callback function. strncpy fails silently.
Frank Hickman [MVP]
news:%23esS43d...@TK2MSFTNGP14.phx.gbl...
> Sandeep <sandeep...@gmail.com> wrote:
>> William DePalo [MVP VC++] wrote:
>>> "Jack" <j...@knight.com> wrote in message
>>> news:OanE28VI...@TK2MSFTNGP10.phx.gbl...
>>>> If I still make use of functions like strcpy, would the final
>>>> machine code for that little part be 16-bit?
>>>
>>> No. It simply means that the usage of the function is discouraged
>>> and at some time in the future it _may_ be removed from the library.
>>
>> removing functions like strcpy would mean giving up the compatibility
>> with C , even though you did mention it as a _may_ , i am still
>> interested in knowing _why_ are these methods deprecated in vc8
>
> They are not really deprecated, in the sense that there are no plans to
> remove them any time soon. It's just that #pragma deprecated is the only
> available mechanism at this time to produce a warning every time a
> function is used, hence a somewhat misleading message.
>
> As to the reason for the warning, see
>
> http://msdn2.microsoft.com/en-US/library/8ef0s5kh.aspx
>
> --
> With best wishes,
> Igor Tandetnik
>
Yes, I knew I saw this somewhere, thank you Igor.
Tim Roberts
>Sandeep <sandeep...@gmail.com> wrote:
>> William DePalo [MVP VC++] wrote:
>>>
>>>> If I still make use of functions like strcpy, would the final
>>>> machine code for that little part be 16-bit?
>>>
>>> No. It simply means that the usage of the function is discouraged
>>> and at some time in the future it _may_ be removed from the library.
>>
>> removing functions like strcpy would mean giving up the compatibility
>> with C , even though you did mention it as a _may_ , i am still
>> interested in knowing _why_ are these methods deprecated in vc8
>
>They are not really deprecated, in the sense that there are no plans to
>remove them any time soon. It's just that #pragma deprecated is the only
>available mechanism at this time to produce a warning every time a
>function is used, hence a somewhat misleading message.
Yes. This was a very unfortunate choice of words on Microsoft's part.
Deprecation has a very specific meaning in the standards process, and
Microsoft's use in this case is not in compliance with that meaning.
Microsoft does not own the C and C++ standards, and therefore does not have
the right to declare certain perfectly valid standard library functions as
"deprecated", especially since they made the warnings enabled by default.
I don't buy the "#pragma deprecated is the only available mechanism"
argument. #pragmas are all entirely compiler-specific. Microsoft invented
"#pragma deprecated" for this release; they were perfectly free to define
another pragma for this case. "#pragma nag" or "#pragma scold" might have
been a better choice.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
adeb...@club-internet.fr
William DePalo [MVP VC++] wrote:
>
> functions:
>
> http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx
>
> but nothing is removed yet.
>
> Just by the way, not everyone is convinced that this is a good idea.
What is considered by some a bad idea exactly, and why?
Arnaud
MVP - VC
David Wilkinson
Tim:
Good point (and quite amusing!). But seriously, how about "#pragma
security"?
David Wilkinson
![Doug Harrison [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVvzhOQGbT9K0Re6Qg-OU4VGuHq0tAdTu01YlmIjUGm6t_o8g=s40-c)
Doug Harrison [MVP]
I was never in favor of deprecating standard functions, which I think is
pretty much tantamount to deprecating pointers. I wrote this the other day:
http://groups.google.com/group/microsoft.public.dotnet.languages.vc/msg/8c56c8405afedd90
<q>
The "safe" functions don't provide
any additional safety for people who use the "unsafe" functions correctly.
As I see it, the primary value in deprecating the "unsafe" functions in
favor of "safe" ones that have size parameters is to force people to think
a little harder about what they're saying. The thing about the "safe"
functions is that without deprecating the traditional, "unsafe" functions,
no one would use the "safe" functions, and you couldn't force people to
think a little harder. Unfortunately, the effect it has on those who've
thought long and hard for years is to irritate them. :) And make no mistake
about the "safe" functions, mistakes will still be made; I reported at
least two bugs in which someone "fixed" MSDN examples by supplying size
arguments in the form of sizeof(ptr) when he really needed to provide an
array size.
Note also the compiler doesn't require you to check the return value of the
"safe" functions. However, MS did get the parameter validation default
behavior right. Unlike what Windows did with lstrcpy, having it swallow
access violations and return an error code which no one checks because
everyone expects lstrcpy to succeed, the CRT invokes an invalid parameter
handler which raises an access violation by default. The question is, do
these functions treat all errors they detect in this way? Offhand, I don't
know, but I hope they do. I also hope those who "want to keep my program
from crashing" never discover _set_invalid_parameter_handler.
</q>
To continue that thought, consider this program:
#include <string.h>
#include <strsafe.h>
int main()
{
char* p = new char[100];
strcpy_s(p, sizeof(p), "1234567890");
//StringCchCopy(p, sizeof(p), "1234567890");
}
The strcpy_s call causes a crash, which is good, while the StringCchCopy
version simply returns an error code. To get full value out of the
<strsafe.h> functions, the compiler needs to provide a
__declspec(checkreturncode) for their declarations to use. Of course, you
can still err on the high side for the size, and I suspect neither family
of "safe" functions can help much with that.
--
Doug Harrison
Visual C++ MVP
Igor Tandetnik
> The strcpy_s call causes a crash, which is good, while the
> StringCchCopy version simply returns an error code. To get full value
> out of the <strsafe.h> functions, the compiler needs to provide a
> __declspec(checkreturncode) for their declarations to use.
You mean, like __checkReturn specifier?
http://msdn2.microsoft.com/ms235402.aspx
http://blogs.msdn.com/martynl/archive/2005/10/10/479332.aspx
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
Doug Harrison [MVP]
wrote:
>You mean, like __checkReturn specifier?
>
>http://msdn2.microsoft.com/ms235402.aspx
>http://blogs.msdn.com/martynl/archive/2005/10/10/479332.aspx
Something like that. :) It looks like you need to use the /analyze switch
to activate the annotations, but for functions for which checking the
return code is essential, I'd want to activate the annotation by default.
But yeah, this is definitely good stuff.
William DePalo [MVP VC++]
news:1138279049....@g44g2000cwa.googlegroups.com...
>> Just by the way, not everyone is convinced that this is a good idea.
>
> What is considered by some a bad idea exactly, and why?
You know, Arnaud, I forget whose messages contained the comments to which I
was referring. They may have been from Holger or Doug. And I don't remember
if the issue was around the questionable "deprecation" warning or of it was
more substantive. And I'm not sure if the conversation was in a public or
private setting where the discussion took place.
Regards,
Will