Alternatives to MS strncpy_s

Question

What are some alternatives to the Microsoft security enhanced functions such as strncpy_s or _itoa_s? Although developing in MS environment the goal is to write code that could be ported easily to other platforms.

Answer 1

If you really want to program in C:

Use the plain old standard strncpy.

If you're programming in C++:

Use the plain old standard string class std::string.

(hint: You probably want the latter. C strings are just bugs waiting to happen, even if you use the "secure" *_s functions. C++ added a string class for a reason)

Answer 2

std::string s(Cstring, n);

Answer 3

Rageous is correct, there is no complex logic behind it.

I would just use Microsoft's version for now and if you decide to port to another OS later, THEN implement it yourself for the target platform and use preprocessor commands to specify your implementation on the non-Windows platform(s).

Answer 4

Try strlcpy. Though not standard C, it exists on a number of platforms and you can download implementations as the source code is available free of charge. See http://www.gratisoft.us/todd/papers/strlcpy.html

Answer 5

I think @codeLizard is asking about how to write compatible code to handle all the functions that Microsoft has deprecated in favor of their secure versions, not just the string functions.

Functions based on Microsoft's secure functions are included in Annex K of the C11 standard, but the annex is not widely supported outside of MSVS.

You can write macros and inline functions in an include file to map back and forth between some of the traditional and secure versions. I posted a set of conversion macros here, If you want to copy them, get them from the liked page; more complete, better comments than below.

However, the approach doesn't work for mapping traditional functions to the secure versions that take size arguments unless the size arguments are also present in the traditional functions. Also, the secure functions differ in exception behaviors, and sometimes in return values. My current conversions don't account for that. When I have time, I'll attempt to improve them where I can to do just that. In the meantime, I'll leave it as an exercise for the reader.

I recommend using the secure functions in new code if you can, use the macro plus function solution if portability to non-MS compilers if required, and also as a bridge for reusing legacy code until you have time to update it with the secure functions.

Here is an abbreviated version of the above linked macro / inline function approach:

#pragma once
#if !defined(FCN_S_MACROS_H)
   #define   FCN_S_MACROS_H
   #include <cstdio>
   #include <string> // Need this for _stricmp
   using namespace std;

   #if (defined(_MSC_VER) && (_MSC_VER >= 1400) ) // _MSC_VER==MSVC 2005 

      // The function plus macro strategy could be used to maintain
      // consistent exception behaviors and return values. 
      inline extern
      FILE*   fcnSMacro_fopen_s(char *fname, char *mode)
      {  FILE *fptr;
         fopen_s(&fptr, fname, mode);
         return fptr;
      }
      #define fopen(fname, mode)               fcnSMacro_fopen_s((fname), mode))

      #define fprintf(fptr, ...)               fprintf_s((fptr), __VA_ARGS__)
      #define fscanf                           fscanf_s
      #define strncpy(dest, source, count)     strcpy_s((dest), (count), (source))
      // Can't map sprinf to sprintf_s (size argument unavailable). 
      //    #define sprintf                    ???


      ...
    #else
      #define fopen_s(fp, fmt, mode)          *(fp)=fopen( (fmt), (mode))
      #define fprintf_s                        fprintf
      #define fscanf_s                         fscanf
      #define strcpy_s(dest, count, source)    strncpy( (dest), (source), (count) )
      ...
    #endif //_MSC_VER
#endif // FCN_S_MACROS_H

Answer 6

Just use strncpy and disable the warning in VC++.

Answer 7

As far as I understand, strncpy_s has no complex logic: just takes minimum of string length, source and destination data sizes and copies resulting amount of chars into destination. If you need it so much, why not to implement it yourself?

Answer 8

You may be interested in the Apache Portable Runtime project:

The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations.

autoconf can also take care of some of these platform-specific differences (by setting #defines, etc), although my experience with it under Windows leaves something to be desired.

Answer 9

Yes, try the https://rurban.github.io/safeclib/.

This is the platform independent implementation of the C11 Annex K on top of all libc's. It is mostly compatible to the Windows sec_api. Windows deviates a bit from the spec with some functions.

strncpy_s is one of the most tricky APIs in the sec_api. Windows does not detect overflow of the two lengths, not an overlap of the two strings. And what to do when the 4th argument count = 0 is also questionable. The spec http://en.cppreference.com/w/c/string/byte/strncpy says A zero return value implies ... that the result in s1 is null terminated, but on windows this is wrong. It just aborts too early. See e.g. the wine implementation: https://github.com/mirror/reactos/blob/master/reactos/lib/sdk/crt/wine/heap.c#L577

And for the _s secure suffix one should assume that wrongly copied bytes into the destination buffer are cleared from prying eyes when an run-time error occured. Not so on Windows with their sec_api. They just set the very first byte to 0.

https://github.com/rurban/safeclib/releases

Answer 10

You could either provide an own implementation for platforms that don't have this function. Or use a macro to reduce the arguments by one and map to the standard string function.