Ctype.h Download

0 views

Skip to first unread message

Alexandrie Gallup

unread,

Aug 3, 2024, 5:51:53 PM8/3/24

to stabnaboojac

I've got the infamous error message in C++ build: "Cannot open include file: 'ctype.h'". I know a similar question was already asked multiple times, but my case seems different because I am using the latest Visual Studio 2022 and seems to behave differently.

Now I can open my solutions, it nicely shows they are using C++ build tools 2015, which I installed together with VS2022, and the solutions also shows correctly that they use Windows 8.1 SDK. But Windows 8.1 SDK is not present in VS2022 installation, I installed it separately. I also tried to "repair" VS2022 installation, but that only deleted all my UI preferences, but not fixed anything in build. Also, I tried to reinstall Windows 8.1 SDK, but it said it is already OK.

So it says that winnt.h from windows kits 8.1 cannot find ctype.h. And yes, there is no ctype.h in that folder or anywhere around, I can see it only in C:\Program Files\Microsoft Visual Studio\2022\Professional\SDK\ScopeCppSDK\vc15\SDK\include\ucrtwhich I think is the folder with VC++ 2015 build tools. So this seems correct, but I am wondering why this folder is not a part of default include directories when VC++ 2015 build tools are set in project settings. Because it seems that VS2022 is correctly picking my Windows 8.1 SDK, but not picking correctly the older C++ compiler.

When I try to add the folder where ctype.h resides to include folders, I receive another type of errors saying that other files are incompatible with these include files. Of course, this system of directories needs to be in sync. So please what is the correct way of using this?

Also, I tried to switch the VC++ build tools to 2022 version. Unfortunately, that also does not fix the issue. And Windows 10 SDK is not installed, the software wants to stay compatible with older Windows, so I don't need it.

Although Microsoft staff declined to accept it as a bug, it is happening for me as well. When I install only Windows 8.1 SDK, no project can be compiled with it. I even tried to create a new Windows API project in VS2022, the project was created, but failed to compile with the same error.

In my case with 10.0.19041 the ucrt headers were installed under C:\Program Files (x86)\Windows Kits\10\ but builds were searching C:\Program Files\Windows Kits\10\. No amount of adding components, repairing, or reinstalling helped. Possibly it's related to having old versions of VS on the machine.

but the first already looked correct, the second didn't help, and the third made me fear masking rather than fixing the issue. Ultimately what actually helped was finding the "KitsRoot10" key in HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Roots and HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Kits\Installed Roots and making sure both had the right path, and restarting Visual Studio. It was immediately fixed, but I did a trial of uninstalling and reinstalling the SDK one last time just to make sure things remained stable.

'Diagnostic' level verbose build output pointed me at the broken IncludePath env var and the file Microsoft.Cpp.WindowsSDK.props it came from. Picking through the props file is how I found the registry key. And after everything was done, I found this same key problem in !

The problem in not that you don't have ctype.h because you need it to compile your program. In your case it depends on the way gdb is locating includes. Maybe you need to use "locate ctype.h" and set inside gdb the include-directory like:

A null-terminated byte string (NTBS) is a sequence of nonzero bytes followed by a byte with value zero (the terminating null character). Each byte in a byte string encodes one character of some character set. For example, the character array '\x63','\x61','\x74','\0' is an NTBS holding the string "cat" in ASCII encoding.

Note: additional functions whose names begin with either to or is, followed by a lowercase letter, may be added to the header ctype.h in future and should not be defined by programs that include that header.

Now, I'm very new to CVI2013 so I don't pretend to be able to explain what's happening. I'm using 2013SP1 and my configuration is the default one (I made no customizations after install): in Options >> Build Options >> Build Process Options panel Standard CVI Compiler is selected both for 32- and 64-bit configurations, __clang__ macro is not included in predefined macros and wchar_t definition is taken from [CVIdir]\include\ansi folder.

As I see inside Options >> Build Options >> Build Process Options it is possible to configure compiler only for Release build configuration. But I'm trying to build a project in Debug configuration. So this option shouldn't affect my compilation process.

CVI 2013 Release Notes says that now Clang is used as a Native CVI compiler. Maybe that is the reason why even in DEBUG configuration compiler runs inside #ifdef __clang__ statement. But this conclusion makes a mash because the following link says that keyword __typeof__ is not supported anymore in CVI 2013 but exactly this keyword used in [CVIdir]\include\clang\stddef.h

The LabWindows/CVI compiler is now using the LLVM compiler infrastructure with a Clang C front end. The updated compiler generates optimized code, meaning that you no longer need to use an external optimizing compiler for this purpose.

I'm not sure about the exact meaning of all that, but it seems to me that this does not implies the use of clang compiler. In effect, in my configuration wchar_t is taken from [CVIdir]\include\ansi\ctype.h file and not in clang or clang\2.9 folders. ctype.h is included before stddef.h in ansi_c.h and does not handle __clang__ macro.

Strange, I'm having the same error now after recompiling an old CVI2015 project with CVI2019. wchat_t is clearly defined in other parts of the code, but missing in some. There must be some weird #undef in some parts of the headers.