From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 06:09:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA531065672 for ; Tue, 24 Feb 2009 06:09:22 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 9EF848FC1A for ; Tue, 24 Feb 2009 06:09:21 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 24 Feb 2009 06:09:20 -0000 Received: from p54A3E245.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.226.69] by mail.gmx.net (mp005) with SMTP; 24 Feb 2009 07:09:20 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+Ih6BpLw6IryUma7yCAHyAGQUHg516mtTNHt2klP J0FdDoPVrsxv1i Message-ID: <49A38F0F.8040008@gmx.de> Date: Tue, 24 Feb 2009 07:09:19 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Hans Petter Selasky References: <20090206045349.GQ78804@elvis.mu.org> <200902091534.12506.hselasky@c2i.net> <49904238.50505@gmx.de> <200902091608.34376.hselasky@c2i.net> In-Reply-To: <200902091608.34376.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: usb@freebsd.org, freebsd-current@freebsd.org, Alfred Perlstein Subject: Re: HEADSUP usb2/usb4bsd to become default in GENERIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 06:09:23 -0000 Hans Petter Selasky schrieb: > On Monday 09 February 2009, Christoph Mallon wrote: >> Hans Petter Selasky schrieb: >>> On Monday 09 February 2009, Christoph Mallon wrote: >>>> Hans Petter Selasky schrieb: >>>>> On Monday 09 February 2009, Christoph Mallon wrote: >>>>>> Christoph Mallon schrieb: >>>>>>> are named "err" or "error". This should be investigated, so here's >>>>>>> the complete list: >>>>>> Sorry, my MUA seems to have damaged the list. You can get the list >>>>>> here: http://tron.homeunix.org/usb2.unread.log >>>>> I think some of these errors depend if you have USB debugging compiled >>>>> or not. At least GCC does not warn? >>>> No, it does not depend on USB debugging. >>>> GCC has no warning at all for variables which are only assigned to. >>>> It only can warn about variables, which are only initialised. >>>> >>>> { >>>> int x = 23; // GCC warns here ... >>>> int y; // ... but not here - cparser does >>>> y = 42; >>>> y++; >>>> } >>>> >>>> cparser has an analysis, which can warn about "y", too. >>>> >>>> I manually verified all 40 warnings and I cannot find any users (i.e. >>>> readers) for these variables. >>> What is the correct way to discard the return argument of a function? >>> That's basically what most of the warnings are about. >>> >>> 1) (void)my_fn() cast >>> 2) if (my_fn()) { } >>> 3) err = my_fn(); >>> 4) my_fn(); >> Just to understand this correctly: You want to discard error codes? >> >> >> Basically I see four categories: >> >> 1) Getting the softc and not using it. >> This can be removed completely. >> Example: >> sc = ATMEGA_BUS2SC(xfer->xroot->bus); >> >> 2) calling mtx_owned() and discarding the return value. >> Can be removed, too, after checking that the value is really unnecessary. >> Example: >> use_polling = mtx_owned(xfer->xroot->xfer_mtx) ? 1 : 0; >> >> 3) Getting some value and not using it. >> Can be removed, too, after checking that the value is really unnecessary. >> Example: >> ep_no = (xfer->endpoint & UE_ADDR); >> >> 4) The rest are return values of functions, which contain error codes. >> Discarding them is questionable at best. >> Example: (err is not read) >> if (udev->flags.suspended) { >> err = DEVICE_SUSPEND(iface->subdev); >> device_printf(iface->subdev, "Suspend failed\n"); >> } >> return (0); /* success */ > > Hi, > > Can you wait some days and re-run the analysis on -current, because there is a > bulk of patches going in to some of the code you have analysed, so the line > numbers are likely to not match. Then we fix those warnings! Here's the updated list: http://tron.homeunix.org/usb2.unread.20090224.log It contains 33 items. 12 of the variables are named "err" or "error".