Menu

False positive syntaxError with GTK enum when using --library=gtk

2026-05-07
2026-05-08
  • correctmost

    correctmost - 2026-05-07

    Hi,

    I am seeing a false positive syntaxError when I run cppcheck -I /usr/include/gtk-3.0/ --library=gtk on this simplified code:

    #include <gtk/gtkenums.h>
    
    int main() {
        return 0;
    }
    

    Output:

    /usr/include/gtk-3.0/gtk/gtkenums.h:825:1: error: syntax error: 0 = [syntaxError]
    

    Here is the relevant code from gtkenums.h:

    824 typedef enum
    825 {
    826   GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH = 0,
    827   GTK_SIZE_REQUEST_WIDTH_FOR_HEIGHT,
    828   GTK_SIZE_REQUEST_CONSTANT_SIZE
    829 } GtkSizeRequestMode;
    

    And here is the relevant definition from gtk.cfg:

    <define name="GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH" value="0"/>
    

    Is this a known issue? Thanks!

    Version info:

    • cppcheck 2.20.0 on Arch Linux
     
  • CHR

    CHR - 2026-05-07

    Using --library and giving cppcheck access to the corresponding headers is not recommended, what happens if you remove -I?

     
    • correctmost

      correctmost - 2026-05-07

      Removing -I helps for this simplified case. I saw this issue while trying to run cppcheck on larger projects like xfce4-places-plugin.

      For those projects, I run cppcheck --enable=all --library=gtk --project=builddir/compile_commands.json. The -I directories seem to get picked up automatically from the JSON data:

      "command": "clang -Ipanel-plugin/libplaces.so.p -Ipanel-plugin -I../panel-plugin -I. -I.. -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/gtk-3.0 ...
      

      I added --library=gtk because I was seeing false positives with g_assert when running cppcheck --enable=all --project=builddir/compile_commands.json:

      panel-plugin/model_system.c:55:8: warning: Either the condition 'bookmark!=((void*)0)' is redundant or there is possible null pointer dereference: bookmark. [nullPointerRedundantCheck]
          if(bookmark->uri != NULL){
             ^
      panel-plugin/model_system.c:53:5: note: Assuming that condition 'bookmark!=((void*)0)' is not redundant
          g_assert(bookmark != NULL);
          ^
      panel-plugin/model_system.c:55:8: note: Null pointer dereference
          if(bookmark->uri != NULL){
             ^
      

      I thought that including gtk.cfg would solve the g_assert false positives, but it ends up introducing the syntaxError on top of the nullPointerRedundantCheck errors.

      It seems like my approach of using --project and --library=gtk is not recommended?

       
  • CHR

    CHR - 2026-05-07

    I see. Maybe -isystem would help?

     
    • correctmost

      correctmost - 2026-05-08

      Hm, I still see the syntaxError with -isystem. I also tried -i/usr/ and -igtkenums.h and got the same error. I guess the /usr/include/gtk-3.0/gtk/gtkenums.h header gets checked indirectly?

      I investigated the false positives with g_assert and found that a GLib header (glib/gtestutils.h) has a g_assert definition that seems to take precedence over the definition from the gtk.cfg file. Is there any way to make the library definition take precedence?

      During my testing, I accidentally created an invalid JSON file (with an extra trailing comma) and crashed cppcheck:

      [
        {
          "directory": "/home/user/code/xfce4-places-plugin/builddir",
          "command": "clang -I/home/user/scratch/include/glib2/ -I/home/user/scratch/include/glib-2.0/include",
          "file": "../panel-plugin/model_system.c",
          "output": "panel-plugin/libplaces.so.p/model_system.c.o"
        },
      ]
      
      $ cppcheck --project=foo.json 
      terminate called after throwing an instance of 'std::runtime_error'
        what():  "type mismatch! call is<type>() before get<type>()" && is<object>()
      Aborted                    (core dumped) cppcheck --project=foo.json
      
       

Log in to post a comment.

MongoDB Logo MongoDB