| Summary: | -Waddress too trigger happy | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Michal Hocko <mhocko> |
| Component: | c | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | manu |
| Priority: | P3 | Keywords: | diagnostic |
| Version: | unknown | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
Btw. the compiler doesn't complain if I rewrite the macro to do an explicit NULL check (maskp != NULL) ? MAX_NUMNODES : 0, (maskp != NULL) ? (maskp)->bits : NULL (In reply to Michal Hocko from comment #0) > While the warning is correct and the given mask will always resolve to the > success path of the ternary operator I really fail to see why we should warn > about this fact. I really do not see any potential problem which could be > caused by this fact. The source code says: c-common.c-3292- /* Common Ada/Pascal programmer's mistake. */ c-common.c-3293- warning_at (location, c-common.c-3294- OPT_Waddress, c-common.c:3295: "the address of %qD will always evaluate as %<true%>", The work-around you found is probably the intended work-around. It would be good to document this. Care to send a patch? https://gcc.gnu.org/contribute.html#docchanges > Moreover the warning itself is quite inconsistent. E.g. the following warns > about the explicit &m but not for n. So I believe this is more of a > suboptimal warning implementation than real intention. This is because the warning is given in the front-end, which does not know the value of n. Not that it matters much, this is really trying to catch a typo, not the actual value of a pointer. (In reply to Manuel López-Ibáñez from comment #2) [...] > > Moreover the warning itself is quite inconsistent. E.g. the following warns > > about the explicit &m but not for n. So I believe this is more of a > > suboptimal warning implementation than real intention. > > This is because the warning is given in the front-end, which does not know > the value of n. Not that it matters much, this is really trying to catch a > typo, not the actual value of a pointer. Would it be possible to skip the warning for macros at least? (In reply to Michal Hocko from comment #1) > Btw. the compiler doesn't complain if I rewrite the macro to do an explicit > NULL check > (maskp != NULL) ? MAX_NUMNODES : 0, (maskp != NULL) ? (maskp)->bits : NULL As it turned out, that workaround only worked for gcc-7 and higher, as well as gcc-4.5 and lower. Anything in-between now prints a variation of "warning: the comparison will always evaluate as ‘true’ for the address of ‘nodes’ will never be NULL". I just sent another workaround to move the comparison into an inline function, which should always work. It appears that at some point during the gcc-7 development, the "comparison will always evaluate as 'true'" logic was turned off for comparisons inside of macros, while the "the address of 'nodes' will always evaluate as 'true'" check did not get changed the same way. |
Hi, in the kernel we have a uggly^Wmacro to help printing numa mask defined as follows #define nodemask_pr_args(maskp) MAX_NUMNODES : (maskp)->bits I have updated it to allow NULL maskp as follows #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL but this has triggered warnings on usage where it is clear that maskp is never NULL. E.g. In file included from include/linux/mmzone.h:17:0, from include/linux/mempolicy.h:10, from mm/mempolicy.c:70: mm/mempolicy.c: In function 'mpol_to_str': include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress] #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL ^ mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' nodemask_pr_args(&nodes)); ^ include/linux/nodemask.h:107:69: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress] #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL ^ mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' nodemask_pr_args(&nodes)); While the warning is correct and the given mask will always resolve to the success path of the ternary operator I really fail to see why we should warn about this fact. I really do not see any potential problem which could be caused by this fact. Moreover the warning itself is quite inconsistent. E.g. the following warns about the explicit &m but not for n. So I believe this is more of a suboptimal warning implementation than real intention. #include <stdio.h> #define MAX_NUMNODES 10 struct mask { void *bits; }; #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL int foo(void) { struct mask m; struct mask *n = &m; printf("%*p\n", nodemask_pr_args(&m)); printf("%*p\n", nodemask_pr_args(n)); return 0; }