Don’t name your header file security.h either

Raymond Chen

May 24th, 20234 3

A customer found that the GetUserNameExW function suddenly disappeared.

error C2065: 'NameSamCompatible': undeclared identifier
error C3861: 'GetUserNameExW': identifier not found

What happened?

These symbols are defined in the header file secext.h in the Windows SDK, and that file was still present on the system and not corrupted. That file is usually not included directly, but rather gets pulled in indirectly when an application includes the header file security.h from the SDK.

Some more exploration revealed that another part of the project added a header file with the name security.h. This collides with the header file of the same name in the Windows SDK, so when the code did a

#include <security.h> // GetUserNameExW

expecting to get the header file from the Windows SDK, it instead picked up the project local version.

We learned some time ago that you shouldn’t name your DLL “security.dll”. And now we learned that the header file name security.h should also be avoided.

(In retrospect, the feature team should have chosen a less common name for their header file and DLL.)

Raymond Chen

Read next

4 comments

Discussion is closed. Login to edit/delete existing comments.

Newest
Newest
Popular
Oldest
  • Sergey Misnik 0

    Same thing with Version.dll – had to rename to something like Revision.dll due to “kernel failed” like exceptions. Probably a good half of System32 directory libraries` names would cause problems.

  • Drew Cooper 0

    > In retrospect, the feature team should have chosen a less common name for their header file and DLL.

    I would bet that “security” was a less common name at the time.

  • Ruben Bartelink 0

    In general, I’d use `#include “security.h” in your example and/or bring it closer to the real scenario (where the double quotes means search including local paths; the angle brackets means “search only system include directories”)

    • 紅樓鍮 · Edited 0

      The angle brackets will instruct the compiler to search all include directories, which include the system include directories but also any directories specified with command line options such as -I. The double quotes instruct the compiler to first search the directory the file being compiled resides in, but then if not found, it will fall back to the include directories regardless.

      Most build systems provide options to specify “additional include directories” when compiling a target. It’s very tempting to add the location of your own project’s header files to that list. What it does is it adds that location to the compiler’s include directory list, meaning it will now be searched when you do either a #include "..." or a #include <...>. But that’s not necessary; you can include your own project headers using the double quotes even without adding that directory to the include directories, and when you want to use system headers, you use the angle brackets and there won’t be the issue of your own headers shadowing homonymous system headers.

      Of course, the issue with not adding your own project headers to the include directories is that it’s only feasible for projects using a flat layout; for projects using split include/ and src/ directories and a complex directory hierarchy under src/, not adding include/ to the include directories means you will need to write, depending on the level under src/ you’re in, varying numbers of ../ to reference files under include/. In that case, it’s better to add include/ to the include directories, but you should create a single subdirectory under include/ named after your project, and put all your headed files under that subdirectory. This way, you minimize the chance your own header files collide with header files provided by the system as well as third parties.

Feedback usabilla icon