On Fri, Sep 15, 2017 at 05:07:31PM +0200, Johannes Berg wrote: > On Fri, 2017-09-15 at 17:05 +0200, Beniamino Galvani wrote: > > On Fri, Sep 15, 2017 at 03:34:40PM +0200, Johannes Berg wrote: > > > On Fri, 2017-09-15 at 14:37 +0200, Beniamino Galvani wrote: > > > > Namespace the __bitwise and __force macros so that they don't > > > > conflict > > > > with the ones from linux/types.h: > > > > > > > > In file included from ../src/l2_packet/l2_packet_linux.c:15:0: > > > > hostap/src/utils/common.h:438:0: warning: "__bitwise" redefined > > > > #define __bitwise > > > > > > > > In file included from /usr/include/linux/filter.h:9:0, > > > > from ../src/l2_packet/l2_packet_linux.c:13: > > > > /usr/include/linux/types.h:21:0: note: this is the location of > > > > the > > > > previous definition > > > > #define __bitwise __bitwise__ > > > > > > I think we can just #ifdef them because it's a compatible, if not > > > exactly identical, definition? > > > > Yes, it's compatible. However, I think there could still be conflicts > > adding an #ifdef because in the kernel header those macros are not > > guarded and so it could happen that a file includes "common.h" and > > then includes another local header file that uses <linux/types.h>, > > causing a redefinition warning. > > I guess I'd say you should include it the right way around - after all, > there's already precedent for this (check the git history of these > definitions) Okay then. Maybe we can just: #ifdef __CHECKER__ #define __force __attribute__((force)) #undef __bitwise #define __bitwise __attribute__((bitwise)) #else #define __force +#undef __bitwise #define __bitwise #endif as in the __CHECKER__ case? '__force' is not actually defined in uapi headers and doesn't require this workaround. Beniamino _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
