Re: How to disable _SECURE_ATL macro

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"Bruno van Dooren" <bruno_nos_pam_van_dooren@xxxxxxxxxxx> wrote
>
>> However, there are places where you're typically perfectly aware
>> of the buffer size. For instance, deprecating memcpy in favor of
>> memcpy_s is a quite stupid motion, IMHO.
>
> the problem with memcpy is that if you are interacting with code that you
> didn't write
> yourself, you cannot be sure that using it is safe.
> in those cases it is better to always use memcpy_s because you have to
> verify with all external buffers anway.
>
I don't quite understand what you're trying to say. Memcpy's contract
clearly defines the size of the buffer accessed.

> unless we are talking about some piece of code where performance is
> critical, i would advise to use the new libaries because they are much
> safer, and in 99.9 % of the cases, the added CPU cycles are un-important.
>
I guess we are not talking about the same thing then. My main complaint
is about Secure SCL which most definitely is not "much safer".

Re memcpy_s et al.: What makes you believe that these functions are
much safer? Carrying the buffer size is tedious and I wouldn't be surprised
if folks just copied the buffer size to memcpy as the fourth paramter.
E.g.
memcpy( foo, bar, size );
becomes
memcpy_s( foo, bar, size, size );

There is obviously no value in this transformation.
Additionally, there are already superior solutions to this problem
by using C++ wrappers. E.g. std::string or std::valarray or any
of the standard containers.

> if performance really is critical then that could be a reason for using
> the un-safe functions, but that shouldn't be the default choice. security
> and stability issues are much more commonplace than performance issues for
> most (but not all) code.
>
I'm afraid I disagree. You don't just throw a switch at the compiler and
your program is magically secure. There is a lot of work involved that
will render your code slower, more complex and less portable. Deprecating
standard functions by default is an extrembly poor choice IMHO.

If you consider buffer management too hard, don't want to use a
managing wrapper and don't care about performance, working set etc.,
you'd probably be better off with another programming language.
Java & C# come to mind.

Obviously, this is a matter of philosophy and maybe personal taste.
However, I definitely do not concur with your initial statement

>of course, it would be MUCH better to port your code to use the new, secure
>functions because doing the things mentioned above will leave you open to
>lots of potential problems.

OTOH, that doesn't necessarily mean you should never use the secure
libraries. But that's what I've done and probably will in the future.

Just my two cents
-hg


.

Relevant Pages

  • Re: VC 2003, WinXP and Win2000
    ... issue does not seen to occur at all under Win2k SP4. ... I am working with the wincrypt, and allocating a buffer to hold some ... first-chance exception under WinXP. ... memcpy() line to the following: ...
    (microsoft.public.vc.language)
  • Re: Efficient scather-gather-copy
    ... memcpythan external programs. ... I can't see that memcpy() would buy you much here, ... passes through the buffer: one to count the newlines and one to ... char *xlate (char *src, size_t len) ...
    (comp.lang.asm.x86)
  • Re: getting thread-ID from another thread
    ... Why do you allocate a fixed-size buffer that is not equal to the length of the ... You are sending the address of the pointer called 'buffer', ... And why are you using memcpy ...
    (microsoft.public.vc.mfc)
  • Re: Microsoft and memcpy?
    ... I'm not sure it's possible to "fix security" with C, ... The secure functions require that the buffer size be ... and memcpy() needs a complying variant if it's ...
    (comp.lang.c)
  • Q: maximizing sequential file read performance
    ... many times above memcpy, and not many times below hardware ... disk IO speed. ... progressivly increase buffer size. ... read the first block from disk into memory, ...
    (comp.os.linux.development.system)