Skip to content

Fixes #14921: Detect enums before simplifying platform types - #8736

Open
autoantwort wants to merge 1 commit into
cppcheck-opensource:mainfrom
autoantwort:feature-fix-platform-types-in-enum
Open

Fixes #14921: Detect enums before simplifying platform types#8736
autoantwort wants to merge 1 commit into
cppcheck-opensource:mainfrom
autoantwort:feature-fix-platform-types-in-enum

Conversation

@autoantwort

Copy link
Copy Markdown
Contributor

No description provided.

@chrchr-github

Copy link
Copy Markdown
Collaborator

This issue has come up multiple times before, and is not restricted to enums or the Windows library, see e.g. https://trac.cppcheck.net/ticket/12589

Contributing factors:

  • We have a single configuration file for huge libraries/APIs with dozens or hundreds of headers
  • The --library option is usually set per project, not per file

I don't think the proposed change is the right way to address this. Maybe -UHANDLE can be used as a workaround?

@danmar danmar left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it OK to redefine HANDLE in the global scope? If I compile this code:

typedef void* HANDLE;
enum {HANDLE, X};

I get such gcc errors:

1.c:3:7: error: ‘HANDLE’ redeclared as different kind of symbol

I assume windows.h defines HANDLE using a typedef?

@danmar danmar left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel there is some missing scope in the example code. HANDLE in the global scope should be simplified as a void * if --library=windows has been used .. and HANDLE in your inner scope should be handled as the enum constant. We need to distinguish which type to use in different scopes..

@autoantwort

Copy link
Copy Markdown
Contributor Author

is it OK to redefine HANDLE in the global scope? If I compile this code:

typedef void* HANDLE;
enum {HANDLE, X};

I get such gcc errors:

If i compile this

typedef void* HANDLE;
enum class E {HANDLE, X};

it compiles without errors.

@autoantwort

Copy link
Copy Markdown
Contributor Author

I don't think the proposed change is the right way to address this.

I guess the right fix would be introducing typedefs for the types instead of replacing them in the AST without context information.

Comment thread test/testtokenize.cpp
}

void platformWinEnumerator() {
// #11538 - HANDLE is a platform type (-> void*) but here it's an enumerator and must not be replaced

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trac ticket 11538 is about a syntax error

@danmar

danmar commented Sep 13, 2026

Copy link
Copy Markdown
Collaborator

I guess the right fix would be introducing typedefs for the types instead of replacing them in the AST without context information.

I think I am thinking the same. However not by introducing some typedef .. tokens if that was what you meant.

To simplify platform types.. can we reuse the logic that simplifies typedefs in simplifyTypedef?

This code:

typedef void* HANDLE;
enum class E { HANDLE, X };
void foo(HANDLE h) { a = E::HANDLE; }

This --debug output looks correct as far as I see:

2: enum class E { HANDLE , X } ;
3: void foo ( void * h@var1 ) { a@exprUNIQUE =@exprUNIQUE E ::@exprUNIQUE HANDLE ; }

And ValueFlow determines the value for E::HANDLE properly.

my suggestion; we would break out code from Tokenizer::simplifyTypedefCpp into a function that we then call from simplifyPlatformType also.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants