I'm dealing with a legacy DLL that has may things that started from DOS C code back in the day where there was no concept of a boolean. But the DLL is still in active development and still evolving. Many of the older exported methods have signatures like:

     _declspec(dllexport) int IsConditionTrue();

By the appearance of the name, the function should return a TRUE/FALSE value, but since it's delcared as an int, the programmer has to assume the API could return anything. I'm in a round of making changes to the DLL, and am wondering if it's safe to change these declarations to use BOOL instead to clarify the intended API usage:

     _declspec(dllexport) BOOL IsConditionTrue();

BOOL is declared as typedef int BOOL;, so I would think that there should be no difference to the compiler or to already-compiled consumers of exported function, right? I just don't want to make the change to a dozen exported functions, then spend a week chasing down and recompiling broken executables that were consuming the exported int version.

CodePudding user response：

BOOL is declared as typedef int BOOL;, so I would think that there should be no difference to the compiler or to already-compiled consumers of exported function, right?

Yes, typedef is just syntactic sugar and has no impact on the resulting ABI.

That said, BOOL does not make the code any safer for the end user, it can still return values other than TRUE, FALSE and compiler will happily accept such code. Furthermore, the user might become more "lazy" and not check these errors compared to ominous int which hopefully makes one actually check the documentation.