From owner-freebsd-multimedia@FreeBSD.ORG Thu Apr 16 14:44:44 2009 Return-Path: Delivered-To: freebsd-multimedia@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08C2D1065676; Thu, 16 Apr 2009 14:44:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C3F128FC20; Thu, 16 Apr 2009 14:44:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA22738; Thu, 16 Apr 2009 17:44:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49E74452.8070000@icyb.net.ua> Date: Thu, 16 Apr 2009 17:44:34 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Alexander Leidinger References: <49E62215.4010309@icyb.net.ua> <20090416143005.74393on2jzdlbts0@webmail.leidinger.net> In-Reply-To: <20090416143005.74393on2jzdlbts0@webmail.leidinger.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org, Rui Paulo , "M. Warner Losh" , John Baldwin Subject: Re: strict signatures for kobj methods in sound subsystem X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 14:44:44 -0000 on 16/04/2009 15:30 Alexander Leidinger said the following: > Quoting Andriy Gapon (from Wed, 15 Apr 2009 21:06:13 > +0300): > >> >> Please review the attached, largely mechanical, patch for sound >> subsystem. >> This patch is supposed to make all functions that implement kobj >> methods have >> strictly the same signatures as defined by the interfaces. > > As you have to change a lot of places, a question would be if it is ok > to change the interface from u_int32_t to int instead. I haven't > investigated if this is about our internal in-kernel interface, or > (indirectly) the official userland OSS interface. I also hadn't a look > what 3rd party sound drivers (e.g. in ports) are using. I think that this would be incorrect because callers of those methods do actually expect uint32_t to be returned, e.g. they assign the result to a variable of such type etc. In fact most of those changed functions do have uint32_t type for the variables that they return. Although uint32_t->int->uint32_t conversion via return doesn't cause any loss or altering of information, it's still not good, IMO. > You are also mixing u_int32_t and uint32_t in the change. Most of them > are of the u_int32_t style, but some changes have uint32_t. Yes, but I am preserving the style of each individual file being changed. -- Andriy Gapon