-1

Our customer urges us to replace unsafe c functions, like snprintf/sscanf/strncat..., with safe versions as snprintf_s/sscanf_s/strncat_s... in our products.

More than replacement, i wonder if any tips on compile/link control to disable our software engineers from using these unsafe c functions in future?

Thanks.

Novak
  • 3
  • 3
  • 1
    You could create a `.h` file with `#define` directives that replace the functions to avoid, and mandate the use of the `.h` file. – ikegami May 08 '20 at 03:13
  • What tool chain are you using? Microsoft's compiler already throws warnings or errors when you use any of the unsafe library calls. – jwdonahue May 08 '20 at 03:34
  • Your customer should really rethink that request... This [old question](https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions) goes over some of the reasons why they're bad. – Shawn May 08 '20 at 06:33
  • The best solution here is to implement code reviewing and testing. – Cheatah May 08 '20 at 06:55

2 Answers2

1

GCC allows poisoning functions that you don't want to use. This can be done using pragma preprocessing directive. For example, the below code won't compile on GCC since printf is marked as poisoned. 

# pragma GCC poison printf

# include <stdio.h>

int main()
{
  printf("Hello World");
  return 0;
}

EDIT: Pragmas are compiler dependent. So if you are using pragmas for poisoning, I'd suggest using them with conjunction of #ifdef and #warning or #error to check compilers as well.

#ifdef __GNUC__
# pragma GCC poison printf
#else
#warning Compiling with compiler other than gcc. Use of unsafe functions not tested
#endif

For checking compilers, refer How to #ifdef by CompilerType ? GCC or VC++

Abhay Aravinda
  • 878
  • 6
  • 17
  • GCC poisons stl and system apis as side effect, which is unexpected and not helpful in a big existing project. I can put all the poisons in a separate header, but I cannot manually include it in every source file and make it the last included to not poinson system libs. Any automatic approach on helping this? Thanks. – Novak May 15 '20 at 03:20
  • @Novak Do you have a specific list of system libraries that are being affected? If yes, then in the same header file containing poisons, you can also warn/poison header guards of those system libraries to ensure they are included before. If you don't have a list of libraries, then it's probably better not to use pragma. As of now, I can't think of a simple way. – Abhay Aravinda May 15 '20 at 13:14
0

First of all, you could just redefine them like #define snprintf snprintf_s. Their signatures are equal.

If you just want to generate a compiler error, the easiest way would be to always include a header with redefinitions of all functions you would like to block.

Theses redefinitions can generate a syntax error and also give the user the reason for the error:

#include <stdio.h>

#define snprintf {"Unsafe! Use snprintf_s instead!"}
#define sscanf {"Unsafe! Use sscanf_s instead!"}
#define strncat {"Unsafe! Use strncat_s instead!"}

You can create such a header (let's call it force_safe.h) and include it in the beginning of every source file. In GCC you can also do this in the compiler flags (eg. gcc -iforce_safe.h ...).

eeucalyptus
  • 194
  • 5