Date: Thu, 16 Apr 2009 21:04:56 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-multimedia@FreeBSD.org, Rui, Paulo <rpaulo@FreeBSD.org>, "M. Warner Losh" <imp@bsdimp.com>, John Baldwin <jhb@FreeBSD.org> Subject: Re: strict signatures for kobj methods in sound subsystem Message-ID: <20090416210456.00004dda@unknown> In-Reply-To: <49E74452.8070000@icyb.net.ua> References: <49E62215.4010309@icyb.net.ua> <20090416143005.74393on2jzdlbts0@webmail.leidinger.net> <49E74452.8070000@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Apr 2009 17:44:34 +0300 Andriy Gapon <avg@icyb.net.ua> wrote: > on 16/04/2009 15:30 Alexander Leidinger said the following: > > Quoting Andriy Gapon <avg@icyb.net.ua> (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. I agree. > > 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. Ah, ok. I didn't look that carefully at it. This is surely ok. Bye, Alexander.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090416210456.00004dda>