| Message ID | 5ef9fef8-e5ee-4ce3-a78f-ee7c35e5a1a4@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | MISRA and -Wextra-semi | expand |
On Fri, 26 Apr 2024, Andrew Cooper wrote: > So, while -Wextra-semi is definitely useful to find some hidden > problems, it seems like using it fully might be very complicated. How > much do we care? I'll let Roberto confirm, but I wouldn't think -Wextra-semi is high priority
On 26.04.2024 13:33, Andrew Cooper wrote: > Hi, > > Based on a call a long while back, I experimented with -Wextra-semi. > This is what lead to 8e36c668ca107 "xen: Drop superfluous semi-colons". > > However, there are a number of problems with getting this working > fully. First, we need workarounds like this: > > diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h > index d888b2314daf..12e99c6dded4 100644 > --- a/xen/include/xen/config.h > +++ b/xen/include/xen/config.h > @@ -26,7 +26,7 @@ > > #include <asm/config.h> > > -#define EXPORT_SYMBOL(var) > +#define EXPORT_SYMBOL(var) typedef int var##_ignore_t For this specifically, could we perhaps finally get rid of most (all?) EXPORT_SYMBOL()? If not all, then at least as far as permitting the stub #define to be moved to linux-compat.h? Jan
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index d888b2314daf..12e99c6dded4 100644 --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -26,7 +26,7 @@ #include <asm/config.h> -#define EXPORT_SYMBOL(var) +#define EXPORT_SYMBOL(var) typedef int var##_ignore_t /* * The following log levels are as follows:
Hi, Based on a call a long while back, I experimented with -Wextra-semi. This is what lead to 8e36c668ca107 "xen: Drop superfluous semi-colons". However, there are a number of problems with getting this working fully. First, we need workarounds like this: to avoid a failure for users, which do legitimately have a semi-colon. It occurs to me that we could swap the typedef for as asm("") which might be a little less unpleasant. But with the simple cases taken care of, we then hit: In file included from common/grant_table.c:3813: common/compat/grant_table.c:10:1: error: extra ';' outside of a function [-Werror,-Wextra-semi] CHECK_grant_entry_v1; ^ which is quickly starting to unravel. Finally, while Clang does have -Wextra-semi working properly for C, GCC does this: cc1: warning: command-line option ‘-Wextra-semi’ is valid for C++/ObjC++ but not for C instead, which passes the cc-option-add check (which doesn't contain -Werror), but causes the real build to fail. So, while -Wextra-semi is definitely useful to find some hidden problems, it seems like using it fully might be very complicated. How much do we care? ~Andrew