strcpy_s / strcat_s / sprintf_s

strcpy_s / strcat_s / sprintf_s

• Peter Han

  Thanks, that's good feedback. We'll work to improve the docs.
  
  Note that the buffer filling only takes place in debug, and is an aid to help you ensure you have passed the right sizes. In retail, we do not fill these buffers.
  
  Martyn Lovell
  Development Lead
  Visual C++ Libraries
  
  

• ogtr

  I think they are all practically the same
  It's nice to add security features when it comes to buffers
  but for c++ developers, you should assume they know what they are doing
  and 'features' should not come in until explicitly requested
  

• CharlesGDL

  I'd probably recommend switching even before those functions included in Standard. For other platforms you always can write wrappers yourself, e.g.
  
  #if not defined(_MSC_VER)
  
  errno_t memcpy_s(
     void *dest,
     size_t sizeInBytes,
     const void *src,
     size_t count
  )
  {
      assert(count <= sizeInBytes);
      memcpy(dest, src, count);
  #if defined(DEBUG)
      memset(count+(char*)dst, 0xFD, sizeInBytes-count);
  #endif
      return 0;
  }
  
  #endif
  
  I understand your concern about need to modify your code agian if Standard Committee decides to change API, but I believe finding several extra bugs in your application because of better checks is worth the risk.
  
  And if you can avoid just one extra service release to fix security hole, you'll be in a big win.

  
  
  

• srivathsan

  Sorry, still don't follow.
  
  Why you need to disable those functions Just don't use them. Call memcpy()/memmove()/whatever instead.
  
  

• YESChandana

  NNTP User wrote:

  "anonymous@discussions.microsoft.com" <OneRing@discussions.microsoft.com> wrote in message news:2f4648c6-b598-4cf8-8722-4a6b0c1b5ce4_WBRev3_@discussions.microsoft.com >  Eugene > Nalimov wrote: Sorry, still don't follow.  > > Why you need to disable those functions Just don't use them. Call > memcpy()/memmove()/whatever instead. > > my project, when compiled with vc7.1, link to memcpy, and when > compiled with vc8, links to memcpy_s > u don't know   No. If you call memcpy, whether in VC7.1 or VC8, you link to memcpy. If you call memcpy_s, you link to memcpy_s. Nobody is switching functions behind your back or anything - it would be impossible anyway, since memcpy_s requires an extra parameter that your code obviously does not pass to memcpy. -- With best wishes,     Igor Tandetnik

  
  
  One obvious fact is that on one would bother to replace his old code base line by line for memcpy with memcpy_s, am I being outdated
  
  
  

• Itai R

  "anonymous@discussions.microsoft.com"
  <OneRing@discussions.microsoft.com> wrote in message
  news:7bb8da2f-2dd3-4f1a-97b0-3ea507fa09ba_WBRev1_@discussions.microsoft.com
  >> No. If you call memcpy, whether in VC7.1 or VC8, you link to memcpy.
  >> If you call memcpy_s, you link to memcpy_s. Nobody is switching
  >> functions behind your back or anything - it would be impossible
  >> anyway, since memcpy_s requires an extra parameter that your code
  >> obviously does not pass to memcpy.   
  >
  > One obvious fact is that on one would bother to replace his old code
  > base line by line for memcpy with memcpy_s, am I being outdated

   

  I'm not sure I understand the question. If you are asking whether one is forced to replace all occurences of memcpy with memcpy_s when porting to VC8, then the answer is no. Nobody forces you. Your current code using memcpy will happily compile.

   

  If you are asking whether one should bother to do this conversion, I'd say it depends. For an existing mature project in maintenance mode, it's probably not worth the effort. For a new project, or a project under active development, this may be considered. Even then, I personally wouldn't rush with it until the Secure CRT extensions are standardized and/or widely available on other compilers and platforms, even if you only ever intend to compile on VC8 under Windows. I'd wait a bit until I can be reasonably sure the API has stabilized, that there is a consensus on what it should look like. The ISO/IEC Technical Report is a great step in this direction, hopefully it will be finalized and progress from Working Draft stage soon:

   

  http://www.opengroup.org/platform/single_unix_specification/uploads/40/6355/n1093.pdf

  
  --
  With best wishes,
      Igor Tandetnik

  
  

• aviatordave

  "anonymous@discussions.microsoft.com"
  <OneRing@discussions.microsoft.com> wrote in message
  news:2f4648c6-b598-4cf8-8722-4a6b0c1b5ce4_WBRev3_@discussions.microsoft.com
  > [quote user="Eugene
  > Nalimov"]Sorry, still don't follow. 
  >
  > Why you need to disable those functions Just don't use them. Call
  > memcpy()/memmove()/whatever instead.[/quote]
  >
  > my project, when compiled with vc7.1, link to memcpy, and when
  > compiled with vc8, links to memcpy_s
  > u don't know

   

  No. If you call memcpy, whether in VC7.1 or VC8, you link to memcpy. If you call memcpy_s, you link to memcpy_s. Nobody is switching functions behind your back or anything - it would be impossible anyway, since memcpy_s requires an extra parameter that your code obviously does not pass to memcpy.
  --
  With best wishes,
      Igor Tandetnik

  
  

• Wei Wang father of twins

  and as u may see, that my original question,
  how do I ...
  ' disable these and switch back to plain old memcpy, memmove ...'
  

• Karthik Mohan

  "anonymous@discussions.microsoft.com"
  <OneRing@discussions.microsoft.com> wrote in message
  news:18ea2e74-274d-4e5e-9e27-533a81b93d09@discussions.microsoft.com 
  > I think they are all practically the same
  > It's nice to add security features when it comes to buffers
  > but for c++ developers, you should assume they know what they are
  > doing and 'features' should not come in until explicitly requested

   

  ... and you explicitly request them when calling strcpy_s instead of plain strcpy. If you don't want the security feature, don't use *_s functions. Nobody twists your arm and forces you to call them.
  --
  With best wishes,
      Igor Tandetnik

  
  

• Rassol

  Eugene Nalimov wrote:

  Sorry, still don't follow. Why you need to disable those functions Just don't use them. Call memcpy()/memmove()/whatever instead.

  
  
  my project, when compiled with vc7.1, link to memcpy, and when compiled with vc8, links to memcpy_s
  u don't know
  

• edworkerkcmsd

  Sorry, I don't follow. All standard unsafe functions as memcpy()/strcpy()/etc. are still there. Developer can use them if (s)he wants.
  
  And yes, safe functions were added after lot of customers requested them. It happened that almost every product group inside MS implemented their one "safe" functions, so we decided it'll be a good idea to add one (standarized) set.
  
  MS submitted those functions to ANSI/ISO Standard Commitee, so there is good chance they will become part of Standard and other compilers will implement them as well.
  
  

• GnomeKing

  By the way: You can disable this feature with "_CrtSetDebugFillThreshold":
  
  #include <string.h>
  #include <crtdbg.h>

  void main()
  {
    _CrtSetDebugFillThreshold(0);
    char pStr[10];
    strcpy_s(pStr, "Test");
  }
  
  But it is also not documented...
  
  See also:
  http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=5d72c30d-5090-4df3-bf95-461c2ea89be8
  
  Greetings
    Jochen

  
  
  

• Test55

  Hi!
  

  Is there any way to disable these and switch back to plain old memcpy, memmove ...

  What do you mean What has this to do with strpcy_s
  

  -- 
  Greetings
   Jochen Kalmbach
   Microsoft MVP VC++
  
    My blog about Win32 and .NET
    http://blog.kalmbachnet.de/
    
  PS: Please mark an answer as "answered" if it helped!!!

  
  

• EliasTa

  Is there any way to disable these and switch back to plain old memcpy, memmove ...
  
• strcpy_s / strcat_s / sprintf_s