Re: [trace:trace/for-next 28/29] include/trace/events/sunrpc.h:703:4: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead)

[Nathan Chancellor <nathan@kernel.org>]

On Thu, Feb 29, 2024 at 06:55:58PM -0500, Steven Rostedt wrote:
> On Thu, 29 Feb 2024 16:44:55 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
> 
> > > I don't build with clang, does this quiet the warning?  
> > 
> > Unfortunately, it does not. I tested with LLVM 17.0.6 from kernel.org:
> > 
> > https://mirrors.edge.kernel.org/pub/tools/llvm/
> > 
> > If there is no other way to silence it, we could potentially use the
> > diag infrastructure to silence it, I could look at that tomorrow.
> 
> Is it the exact same warning? I wonder if I make it into an if statement,
> it would be better?
> 
> #define __assign_str(dst, src)						\
> 	do {								\
> 		char *__str__ = __get_str(dst);				\
> 		int __len__ = __get_dynamic_array_len(dst) - 1;		\
> 		if (__builtin_constant_p(src))				\
> 			WARN_ON_ONCE(strcmp((src), __data_offsets.dst##_ptr_)); \
> 		else							\
> 			WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_);\
> 		memcpy(__str__, __data_offsets.dst##_ptr_ ? :		\
> 		       EVENT_NULL_STR, __len__);			\
> 		__str__[__len__] = '\0';				\
> 	} while (0)
> 
> Then the compiler may be better in optimizing out the "bad" portion.

No, that does not work either, I diffed the warnings and they are
identical minus line numbers. I don't think clang takes
__builtin_constant_p() into account in the front end but I could be
wrong. In fact, I think clang (and even gcc sometimes) will still warn
for code even if it is within an 'if (0)' block, it's been used as
justification before in commit 37b47298ab86 ("sched: Disable
-Wunused-but-set-variable").

Cheers,
Nathan