How to Find all non-Unicode Function Calls in Source Code

Question

In my source code I have been extremely careful to use Unicode throughout, always call the wide versions of WinAPI functions, am very careful in my conversions, etc. etc. to support the many users of my program with non-English copies of Windows.

But mistakes creep in, as I am sure you can all understand. I recently ran into a program crash where, in just one place in my code, I called function "isspace" rather than "iswspace".

Is there some tool that allows me to scan my source code for all ANSI function calls, to hopefully find any more mistakes that may be there?

Thank you.

Answer 1

I had problems in a software that I was working on a while back. I found out that the problems were caused by the strcpy(), strcat(), etc. all sorts of string functions that had no protections and could overwrite destination buffers if the source had a problem for whatever reason.

What I have done at the time is write a C parser (I was using C back then...) and detected all function calls (that's easy in the C syntax: '(' is a function call if within a block. In C++ you'll have to detect classes and structures as such too, but that's not much more work.) Now you can generate an error on any function that your software is not supposed to use and that breaks your build.

Free C++ parsers exist "all over the place" so you could use one of those and reuse that code.

Now, there is another way too, which uses the preprocessor: for any function that you do not want your software to use, you create a #define which when used generates an error:

#define isspace function-error "please use iswspace() instead of isspace()"

Of course, that means you need to know the list of such functions in the first place, which as someone else mentioned, you could find by looking at your dynamic library link tables. But the result is that you won't be able to compile your software without fixing a few things first. One problem, you must do that in a header file that gets included last or you could get some problems with your library header files:

#include <boost/shared_ptr.hpp>
#include <non_unicode_function.h>
... your functions ...

That is probably simpler than the C++ parser, but it is probably less fun too... Yet, if once in a while you need to call a forbidden function, you could do an #undef which you document clearly, etc. and restore the value afterward.