Skip to content

Conversation

jserv
Copy link
Contributor

@jserv jserv commented Feb 21, 2025

The 'typeof' operator, originally a GNU extension, is now part of the C23 standard. This change enables its use in list macros where supported.

Change-Id: I6a6e4e0caa4b72f16d957e0bd87722fac1915e3d

The 'typeof' operator, originally a GNU extension, is now part of the
C23 standard. This change enables its use in list macros where
supported and explicitly cuts of non-typeof macros.

Change-Id: I6a6e4e0caa4b72f16d957e0bd87722fac1915e3d
@jserv jserv merged commit 15b4c4f into master Feb 21, 2025
4 checks passed
@jserv jserv deleted the list-typeof branch February 21, 2025 09:16
@scc-tw
Copy link
Contributor

scc-tw commented Feb 21, 2025

@jserv What do you think about the auto type placeholder since C23 (§6.7.9 Type inference)? Is it appropriate to use it here? Thanks!

@jserv
Copy link
Contributor Author

jserv commented Feb 21, 2025

What do you think about the auto type placeholder since C23 (§6.7.9 Type inference)? Is it appropriate to use it here?

It sounds good. Just do it along with effective tests.

@lumynou5
Copy link
Contributor

lumynou5 commented Feb 23, 2025

The #if directives around the difinitions of macros list_for_each_entry and list_for_each_entry_safe break the static analytics of code depending on the macros. I propose to add a type parameter to each of the macros, so they can be used even if we don't have typeof, and the interfaces are also consistent with the list_entry family.

The error:

queue.c:28:5: error: There is an unknown macro here somewhere. Configuration is required. If list_for_each_entry_safe is a macro then please configure it. [unknownMacro]
    list_for_each_entry_safe (entry, safe, head, list)
    ^

@jserv
Copy link
Contributor Author

jserv commented Feb 23, 2025

@lumynou5, which version of Cppcheck are you using? I am using Cppcheck 2.17 dev (build from source) and have not seen such errors.

@lumynou5
Copy link
Contributor

lumynou5 commented Feb 23, 2025

@jserv 2.16.0 from Arch Linux official repositories.

I tested without the #if's, it passes.

@jserv
Copy link
Contributor Author

jserv commented Feb 24, 2025

Cppcheck 2.16.0 from Arch Linux official repositories.
I tested without the #if's, it passes.

You can suggest some inlined Cppcheck suppression comments for me to apply.

@lumynou5
Copy link
Contributor

inlined Cppcheck suppression comments

Because the macros are not defined, cppcheck-suppress-macro comment cannot be used to suppress errors where the macros are used. I think we can add an #else branch to define dummy macros. It results CppCheck suppressed, the parameters unchanged, and code relying on the macros failed to compile -- all as before.

For example

#if __LIST_HAVE_TYPEOF
#define list_for_each_entry_safe(entry, safe, head, member)            \
    for (entry = list_entry((head)->next, typeof(*entry), member),     \
        safe = list_entry(entry->member.next, typeof(*entry), member); \
         &entry->member != (head); entry = safe,                       \
        safe = list_entry(safe->member.next, typeof(*entry), member))
#else
#define list_for_each_entry_safe(entry, safe, head, member)            \
    for (entry = safe = (void *) 1;                                    \
         sizeof(struct { int : -1; });                                 \
         ++(entry), ++(safe))
#endif

The purpose of the assignments and the increments are to avoid CppCheck complaining potential uninitialized variables, unused variables, and can-be-constant variables.

@jserv
Copy link
Contributor Author

jserv commented Feb 26, 2025

Because the macros are not defined, cppcheck-suppress-macro comment cannot be used to suppress errors where the macros are used. I think we can add an #else branch to define dummy macros. It results CppCheck suppressed, the parameters unchanged, and code relying on the macros failed to compile -- all as before.

Create a new issue along with the proposed changes.

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.

4 participants