Re: [PATCH] HID: simplify code in fetch_item()

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Tue, Apr 15, 2025 at 08:21:49AM -0700, Nathan Chancellor wrote:
> On Tue, Apr 15, 2025 at 09:45:58AM +0300, Andy Shevchenko wrote:
> > On Mon, Apr 14, 2025 at 05:33:26PM -0700, Nathan Chancellor wrote:
> > > On Mon, Apr 14, 2025 at 09:30:36AM +0300, Andy Shevchenko wrote:
> > > > On Thu, Oct 10, 2024 at 03:24:51PM -0700, Nathan Chancellor wrote:
> > > > > On Tue, Oct 01, 2024 at 08:42:36AM -0700, Dmitry Torokhov wrote:

...

> > > > > Getting rid of the unreachable() in some way resolves the issue. I
> > > > > tested using BUG() in lieu of unreachable() like the second change I
> > > > > mentioned above, which resolves the issue cleanly, as the default case
> > > > > clearly cannot happen. ...
> > > > 
> > > > As Dmitry pointed out to this old discussion, I have a question about the above
> > > > test. Have you tried to use BUG() while CONFIG_BUG=n? Does it _also_ solve the
> > > > issue?
> > > 
> > > Yes because x86 appears to always emit ud2 for BUG() regardless of
> > > whether CONFIG_BUG is set or not since HAVE_ARCH_BUG is always
> > > respected.
> > 
> > Thank you for the reply. But do you know if this is guaranteed on the rest of
> > supported architectures? I.o.w. may we assume that BUG() in lieu of unreachable()
> > will always fix the issue?
> 
> I don't know. As far as I can tell, BUG() is always better than a bare
> unreachable() because it is either the same as unreachable() if the
> architecture does not define HAVE_ARCH_BUG and CONFIG_BUG=n (and in the
> case of CONFIG_BUG=n, I think the user should get to pick up the pieces)
> or when CONFIG_BUG=y and/or HAVE_ARCH_BUG is defined, the unreachable()
> will truly be unreachable in the control flow graph because of the trap
> or __noreturn from BUG(), so no undefined behavior. I think you would
> only be able to find cases where BUG() was not sufficient to avoid
> undefined behavior at runtime instead of compile time, as objtool only
> supports loongarch and x86 right now and both ensure BUG() always traps.
> I might be missing something though.

Thank you for this information!

-- 
With Best Regards,
Andy Shevchenko