Search code examples
mysqlcvisual-studio-codeincludeinclude-path

Why Visual Studio Code can't find the `ulong/uint` even if the header file path is in the include path?


I'm trying to make Intellisense work on the MySQL source code, using Visual Studio Code on Ubuntu.

The project requires libmysqlclient-dev, which is installed.

Even though I include the development headers path in the includePath:

        "includePath": [
            "/usr/include/mysql",
            "${workspaceFolder}/include"
        ],

(this is a part of the includes required; I've added many others to no avail)

the data types ulong and uint are not recognized, causing a flurry of errors:

identifier "uint" is undefined
identifier "ulong" is undefined
// and so on

This is strange, since I can see both types defined:

/usr/include/mysql/my_global.h
177:typedef unsigned int uint;
497:typedef unsigned long   ulong;        /* Short for unsigned long */
504:typedef unsigned long long int ulonglong; /* ulong or unsigned long long */

And the include directive is present (example file follows):

client/mysqldump.c
43:#include <my_global.h>

What am I missing?


Solution

  • Given the complex use of conditional compilation features such as #if, #ifdef, and #ifndef in the source code (a version is available here), without specific information on your exact environment, it's impossible to say exactly what you need to do.

    But, in general, you need to make sure your environment is such that the lines with the relevant typedef statements are actually included by the C preprocessor in the code that is compiled.

    There are several ways to help determine that. One, you can have your compiler dump all its macros. For MSVC, see How to find out cl.exe's built-in macros. Second, you can examine the output of the preprocessed code. For MSVC see How do I see a C/C++ source file after preprocessing in Visual Studio?.

    Either of those can be of great assistance in seeing what code is actually getting compiled when there are many possible results because of complex #if... preprocessor directives.