Rename standards.h header file

[reshmavk]

Compilation of cppcheck fails in AIX fails with multiple undeclared errors as shown below:

/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:47:11: error: 'int8_t' has not been declared in '::'
   47 |   using ::int8_t;
      |           ^~~~~~
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:48:11: error: 'int16_t' has not been declared in '::'
   48 |   using ::int16_t;
      |           ^~~~~~~
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:49:11: error: 'int32_t' has not been declared in '::'
   49 |   using ::int32_t;
      |           ^~~~~~~
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:50:11: error: 'int64_t' has not been declared in '::'
   50 |   using ::int64_t;
      |           ^~~~~~~
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:52:11: error: 'int_fast8_t' has not been declared in '::'
   52 |   using ::int_fast8_t;
      |           ^~~~~~~~~~~
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:53:11: error: 'int_fast16_t' has not been declared in '::'

AIX has a system header file named standards.h which defines certain macros based on which types like int8_t,int16_t,etc are defined in stdint.h header file. Since cppcheck also has a header file named standards.h and this takes precedence over the system header file during compilation, system provided standards.h is not included resulting in the above mentioned errors. For more information please refer https://sourceforge.net/p/cppcheck/discussion/development/thread/b5b3f765b4/

To resolve this issue, this PR implements a possible solution: cppcheck provided standards.h has been renamed to cppcheckstd.h and #include "standards.h" has been replaced with #include "cppcheckstd.h" wherever required in the source code.

Could you please let me know if these changes are acceptable to merge or if there is a better approach to address this issue. I appreciate your suggestions.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[chrchr-github]

Thanks for your contribution. For consistency, please rename standards.cpp to cppcheckstd.cpp.
You also need to replace all references to standards.h in Makefile and in https://github.com/reshmavk/cppcheck/blob/rename_standards/tools/dmake/dmake.cpp

[firewave]

In file included from /home/buildusr/reshma/patch_contribution/cppcheck/lib/standards.h:24,
                 from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include-fixed/wchar.h:44,
                 from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cwchar:44,
                 from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/bits/postypes.h:40,
                 from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/bits/char_traits.h:40,
                 from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/string:40,
                 from /home/buildusr/reshma/patch_contribution/cppcheck/lib/matchcompiler.h:23,
                 from /home/buildusr/reshma/patch_contribution/cppcheck/build/lib/build/mc_valueflow.cpp:1:
/home/buildusr/reshma/patch_contribution/cppcheck/lib/config.h:137:26: error: aggregate 'const string emptyString' has incomplete type and cannot be defined
  137 | static const std::string emptyString;
      |                          ^~~~~~~~~~~

I still do not understand how a system include can utilize a local include as those should be separated. That means that any project could "poison" the system ones. Seems like there is a bug in the compiler or the project is misconfigured.

I also do not like the new name as naming something cppcheck*.* is redundant and does not reflect the contents.

[danmar]

@reshmavk do you have a real AIX machine or do you use some cloud service that we could test?

[reshmavk]

I use a real AIX machine, not from the cloud.
Here is a sample code that can reproduce this issue.
main.cpp

#include "standards.h"
#include <iostream>

void say_hello(uint8_t times) {
    for (uint8_t i = 0; i < times; ++i) {
        std::cout << "Hello, World! [" << static_cast<int>(i + 1) << "]" << std::endl;
    }
}

int main() {
    say_hello(3);  // Print Hello World 3 times
    return 0;
}

standards.h

#ifndef HELLO_HPP
#define HELLO_HPP

#include <cstdint>  // Use <stdint.h> if you prefer C-style

void say_hello(uint8_t times);

#endif // HELLO_HPP

The error occurs when compiled using g++ -I<local_path_to_standards.h> main.cpp -o main -lstdc++

[danmar]

@firewave I can reproduce something similar on my debian machine. I put two files in current folder 1.c and stddef.h.

1.c:

#include <stdio.h>
int main() {
    return 0;
}

stddef.h

#error BAD

on my machine stdio.h includes stddef.h using angle brackets:

$ grep stddef.h /usr/include/stdio.h
#include <stddef.h>

my stddef.h in local folder gets included:

$ gcc -I/home/daniel/cppchecksolutions/cppcheck 1.c
In file included from /usr/include/stdio.h:33,
                 from 1.c:2:
/home/daniel/cppchecksolutions/cppcheck/stddef.h:1:2: error: #error BAD
    1 | #error BAD
      |  ^~~~~

If I remove the -I... from the gcc command it compiles.

[danmar]

the first suggestion by chat gpt is to not reuse header filenames. but.. who says that it's only standards.h

we can include using more specific paths i.e.: #include "cppcheck/lib/standards.h". but ugh I have a bad feeling about replacing all the paths..

I don't have very great ideas right now.

[reshmavk]

Can the option "-iquote" be utilised?
Instead of renaming the header file, I replaced -Ilib with -iquote lib thereby ensuring that lib directory is only searched for quoted includes (#include "..."). With the following changes I am able to successfully compile cppcheck in AIX.

--- ./lib/CMakeLists.txt.orig   2026-03-05 04:36:43.738276867 -0600
+++ ./lib/CMakeLists.txt        2026-03-05 04:37:59.114768568 -0600
@@ -49,7 +49,13 @@
 
 target_dll_compile_definitions(cppcheck-core EXPORT CPPCHECKLIB_EXPORT IMPORT CPPCHECKLIB_IMPORT)
 
-target_include_directories(cppcheck-core PUBLIC .)
+if (CMAKE_SYSTEM_NAME MATCHES AIX)
+    set(CMAKE_INCLUDE_CURRENT_DIR OFF)
+    target_compile_options(cppcheck-core PUBLIC -iquote ${CMAKE_CURRENT_SOURCE_DIR})
+else()
+    target_include_directories(cppcheck-core PUBLIC .)
+endif()
+
 target_link_libraries(cppcheck-core PRIVATE tinyxml2 simplecpp picojson ${PCRE_LIBRARY})
 
 if (HAVE_RULES)
--- ./test/signal/CMakeLists.txt.orig   2026-03-05 03:26:57.070604485 -0600
+++ ./test/signal/CMakeLists.txt        2026-03-05 03:30:47.878598314 -0600
@@ -2,7 +2,12 @@
         test-signalhandler.cpp
         ${PROJECT_SOURCE_DIR}/cli/signalhandler.cpp
         ${PROJECT_SOURCE_DIR}/cli/stacktrace.cpp)
-target_include_directories(test-signalhandler PRIVATE ${PROJECT_SOURCE_DIR}/cli ${PROJECT_SOURCE_DIR}/lib)
+if (CMAKE_SYSTEM_NAME MATCHES AIX)
+    target_compile_options(test-signalhandler PRIVATE -iquote ${PROJECT_SOURCE_DIR}/lib)
+    target_include_directories(test-signalhandler PRIVATE ${PROJECT_SOURCE_DIR}/cli)
+else()
+    target_include_directories(test-signalhandler PRIVATE ${PROJECT_SOURCE_DIR}/cli ${PROJECT_SOURCE_DIR}/lib)
+endif()
 if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU" OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
     # names for static functions are omitted from trace
     target_compile_options_safe(test-signalhandler -Wno-missing-declarations)
--- ./test/testfrontend.cpp.orig        2026-03-05 03:14:57.497914601 -0600
+++ ./test/testfrontend.cpp     2026-03-05 03:15:19.966076746 -0600
@@ -16,7 +16,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
-#include <filesettings.h>
+#include "filesettings.h"
 
 #include "fixture.h"
 #include "frontend.h"

Please let me know your thoughts on these changes

[danmar]

Please let me know your thoughts on these changes

basically your problem has nothing to do with AIX. and I therefore think its unfortunate to add special coding for AIX. There is a risk that somebody else will run into the same problem on another system. Or that your problem is solved on your system and then we will still have this code for no reason in our repo.

I am not fundamentally against that we use -iquote. Changing the paths is another alternative that might be more "proper". I am not 100% against that we tweak the folder structure and include some folder names in includes. I.e. cppcheck/lib/settings.h would be explicit.

[firewave]

I still do not understand how this can happen. We also have config.h which also exists in system includes but it does not trigger the issue.

I really would prefer if we have a reproduction case - even if only locally.

[mwmarkland]

I still do not understand how this can happen. We also have config.h which also exists in system includes but it does not trigger the issue.

I really would prefer if we have a reproduction case - even if only locally.

The example here: #8093 (comment) looks like what you need for reproduction, at least with gcc. The gcc documentation lays out how this behavior works:

Section 3.17 Options for Directory Search
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched for header files during preprocessing. If dir begins with ‘=’ or $SYSROOT, then the ‘=’ or $SYSROOT is replaced by the sysroot prefix; see --sysroot and -isysroot.

Directories specified with -iquote apply only to the quote form of the directive, #include "file". Directories specified with -I, -isystem, or -idirafter apply to lookup for both the #include "file" and #include directives.

You can specify any number or combination of these options on the command line to search for header files in several directories. The lookup order is as follows:

• For the quote form of the include directive, the directory of the current file is searched first.
• For the quote form of the include directive, the directories specified by -iquote options are searched in left-to-right order, as they appear on the command line.
• Directories specified with -I options are scanned in left-to-right order.
• Directories specified with -isystem options are scanned in left-to-right order.
• Standard system directories are scanned.
• Directories specified with -idirafter options are scanned in left-to-right order.

You can use -I to override a system header file, substituting your own version, since these directories are searched before the standard system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files; use -isystem for that.

The problem manifests on AIX due to the fact it has a file named standards.h in the system include paths that doesn't get found in the system paths because any -I pointing into the cppcheck source will find the cppcheck version first.

You'll either have to change header names or use some sort of trick like -iquote on AIX to fix this.

[danmar]

Sorry for late reply.

I don't like the options. If we rename settings.h then as firewave says we should probably sooner or later will need to rename config.h also.

Another option is to put the headers in some other folder. all the headers could be moved into a cppcheck folder and then we could write "cppcheck/lib/settings.h" but this is a bigger change so I don't like it.

Is it enough for now to change the includes to #include "lib/settings.h" ? That will make it a bit less likely that we include the wrong header right? I could accept this PR if it changes the code like that and doesn't rename or move any headers.