Re: [PATCH v2] USB hub_probe: remove ugly goto-into-compound-statement

[Eugene Korenevsky <ekorenevsky@gmail.com>]

On Mon, Nov 07, 2016 at 10:09:17AM +0100, Greg Kroah-Hartman wrote:

> > Rework smelling code (goto inside compound statement). Perhaps this is legacy.
> > Anyway such code is not appropriate for Linux kernel.
> > 
> > Signed-off-by: Eugene Korenevsky <ekorenevsky@gmail.com>
> > ---
> >  drivers/usb/core/hub.c | 24 +++++++++++-------------
> >  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> What changed from v1?

Fixed faults: missed 'Signed-off-by', spaces instead of tab.


> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index cbb1467..4081672 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -1802,23 +1802,21 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
> >  
> >  	/* Some hubs have a subclass of 1, which AFAICT according to the */
> >  	/*  specs is not defined, but it works */
> > -	if ((desc->desc.bInterfaceSubClass != 0) &&
> > -	    (desc->desc.bInterfaceSubClass != 1)) {
> > -descriptor_error:
> > +
> > +	/* Reject in following cases:
> > +	 * - Interface subclass is not 0 or 1
> > +	 * - Multiple endpoints
> > +	 * - Not an interrupt in endpoint
> > +	 */
> > +	endpoint = &desc->endpoint[0].desc;
> > +	if ((desc->desc.bInterfaceSubClass != 0 &&
> > +	     desc->desc.bInterfaceSubClass != 1) ||
> > +	    desc->desc.bNumEndpoints != 1 ||
> > +	    !usb_endpoint_is_int_in(endpoint)) {
> >  		dev_err(&intf->dev, "bad descriptor, ignoring hub\n");
> >  		return -EIO;
> >  	}
> >  
> > -	/* Multiple endpoints? What kind of mutant ninja-hub is this? */
> > -	if (desc->desc.bNumEndpoints != 1)
> > -		goto descriptor_error;
> > -
> > -	endpoint = &desc->endpoint[0].desc;
> > -
> > -	/* If it's not an interrupt in endpoint, we'd better punt! */
> > -	if (!usb_endpoint_is_int_in(endpoint))
> > -		goto descriptor_error;
> > -
> 
> As "horrible" as the original code might be, it's much easier to read
> and follow, which is the key thing here, right?  What's so bad about a
> goto backwards?

OK, this patch is still not perfect. But jumping *back* into
*compound* *statement* hurts reader's eyes. Really. Maybe it's better to
extract this code to static function, compiler will inline it. See v3
patchset.

-- 
Eugene