From owner-freebsd-usb@FreeBSD.ORG Mon Feb 9 16:06:11 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03B73106564A for ; Mon, 9 Feb 2009 16:06:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swipnet.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9598FC20 for ; Mon, 9 Feb 2009 16:06:09 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=8UcZu9N6atoA:10 a=rZF0ZLlPMY8A:10 a=mHKO8asG7wzLhKhmW7EWpA==:17 a=N3vH5299AAAA:8 a=Ruid5yuE4hOwrEPXKGEA:9 a=SuN8P6eQdEvpyuhK8lEA:7 a=jGL5X-ozjliaIbx9_VpGlXmfPTQA:4 a=LY0hPdMaydYA:10 Received: from [193.217.167.198] (account mc467741@c2i.net HELO laptop) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 447140681; Mon, 09 Feb 2009 16:06:07 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 9 Feb 2009 16:08:32 +0100 User-Agent: KMail/1.9.7 References: <20090206045349.GQ78804@elvis.mu.org> <200902091534.12506.hselasky@c2i.net> <49904238.50505@gmx.de> In-Reply-To: <49904238.50505@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902091608.34376.hselasky@c2i.net> Cc: usb@freebsd.org, Christoph Mallon Subject: Re: HEADSUP usb2/usb4bsd to become default in GENERIC X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 16:06:11 -0000 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! --HPS