From owner-svn-src-head@FreeBSD.ORG Sat Jul 19 10:46:36 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 033D3FED for ; Sat, 19 Jul 2014 10:46:36 +0000 (UTC) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABC6A2FB8 for ; Sat, 19 Jul 2014 10:46:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1405766787; bh=xYEjUegxztYDWAiIf6J1yfpezV0uKIvN/8J6phFWfDU=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=CZLWBvr8L9gBHjUGb4QKC+WHbDLWvQq2cx7zGdXJank1zMR27sSIFId/rfIVy6zhAyxqqEAIPayIVUUhQ+QUm+6oFjWrOBm2Uj7vvdvdj0/df+n6cjdO2R2+/3hNwVS8lNtaHAU1+hRFnELZzVsetqTJiofaqTlqX6b59q3EanrmQAUEGqKLbXe5/4/ZejIsDN02/odaYTCryRLW9DJWFRc+FM8A7EPcoXAWN20xTdWY/GhrgcdCkNRWh7zT3v7Na5o4bpkG5UiPVHmB0JMPxyoSFn2c9OH5UVqQ7Qe6dhD98/IsQBHruyT1WNwLeb1EgHm3BFYXOPsBADY92PRWGg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=HaYnEPzfk8XsONP/ElXI0lrWFXvkfE9T3Mf/uMk5n8uVxNHKD8lDG9pA1ZVoKCweJkgDwHBzoLbiKKd9PuW27SAuV6kyHIUxOrjPeGi0Fy7dgWms1qktgrjzm6+8Ji4JibUP0cHVliVW0XgjtUFr+WMrs2T2LzNaHYxflTRmbBq3/4RWr+RGVPCn4WGHMv6ap6By8xhGzGkAkuOgRMN9ZG6MNa9FJSoBbBOBMwUmUvTMokONuSt6rEu55TTk05oi4ixztOZN/HNIQVJhDxNaysFCaty1frrEzWj3joRWBnDERYckvnw55eK6L8UhuKIs8nICiwQGPj+RXp8Py+vycw==; Received: from [98.139.212.151] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jul 2014 10:46:27 -0000 Received: from [98.139.211.192] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jul 2014 10:46:27 -0000 Received: from [127.0.0.1] by smtp201.mail.bf1.yahoo.com with NNFMP; 19 Jul 2014 10:46:27 -0000 X-Yahoo-Newman-Id: 715477.91940.bm@smtp201.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8uqhoFoVM1m7_4uPhq.GCYAyxB.U8dejN5_.8.T_WdVczyi PUIveUyd2sCJHYpjr7RVewt5ZbMWEzyyWE5nM65S07TgOJd33zouppNVsuVf p2AeWWzyC9AHrF3.BC5O4_7JvRGycp9ZlTEblpfowxEQHvXhYFgC7LCcRPZG c1hvh8ImBQdOJDWkFtLCm0JkQsC4ZhilTNt2zrCpcH4L7lHbqYXjFi4dMXlu _q410vlK7dBfyWa0NNPqrGjY8iZ7DNYNXZLAcXW.nHvZ4.YGksSZetJkE66Y Aa9UL7bTaIaMN8WU20avew1CajXcXZ2LzdINCYRAU9xSfO3SasCjv7JEGI9Q 1f614VN42g6mov3dVo3aB2xwFYcu3Eu5UYZ0JnJyKrLOwDJpLehjrjxzAcv4 BJcbufRXE.0qe8dzOWfvgNp.zPofq68h8GCByrPj5Gb4tw4j9GV1B0BDDkc9 sq9bSkdOG1NfxWplGN7UA5Sbdy0lj1GoMz2aOrO6mQ2iIBAduyxtRIlO3sLp 9dDCRgwA5bN2uUspGqG28 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svn commit: r268867 - head/lib/libc/net From: Pedro Giffuni In-Reply-To: <20140719171552.W874@besplex.bde.org> Date: Sat, 19 Jul 2014 05:46:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201407190153.s6J1rqBn027367@svn.freebsd.org> <20140719171552.W874@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1878.6) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 10:46:36 -0000 Hello; Il giorno 19/lug/2014, alle ore 02:36, Bruce Evans = ha scritto: > On Sat, 19 Jul 2014, Pedro F. Giffuni wrote: >=20 >> Log: >> Use unsigned optlen in getsourcefilter() >>=20 >> Sizes can not be negative and the functions that use it >> expect an unsigned value anyways. >>=20 >> Obtained from: Apple (Libc-997.90.3) >> MFC after: 1 week >=20 > Most uses of unsigned types are bugs. This one is an exception, but = the > change is still wrong. The critical use of the type needs it to be > socklen_t, not int or unsigned int. socklen_t happens to have type > uint32_t (unsigned due to old bugs). It only accidentally has the > same size as unsigned int. It has a different type to plain int so > compilers should warn about the type mismatch with certain warning > flags. >=20 Ah, yes, we have had this discussion before =85 in relation with ext2fs = ;). The compiler doesn=92t have a way to tell if socklen_t is of a certain = type "by accident=94. I will use socklen_t in this case instead of unsigned int, but I will = not MFC the changes as the original change has no functional (end-user) effect. =20 >> Modified: >> head/lib/libc/net/sourcefilter.c >>=20 >> Modified: head/lib/libc/net/sourcefilter.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/lib/libc/net/sourcefilter.c Sat Jul 19 01:15:01 2014 = (r268866) >> +++ head/lib/libc/net/sourcefilter.c Sat Jul 19 01:53:52 2014 = (r268867) >> @@ -337,7 +337,8 @@ getsourcefilter(int s, uint32_t interfac >> { >> struct __msfilterreq msfr; >> sockunion_t *psu; >> - int err, level, nsrcs, optlen, optname; >> + int err, level, nsrcs, optname; >> + unsigned int optlen; >=20 > This has mounds of style bugs. 2 more now (unsorting, and not using > u_int, except u_int is not just a style bug) >=20 While aesthetically it may be better to keep the sorting, it doesn=92t = seem correct to preserve it at the expense of setting the incorrect = type. Would you really want me to set optname in another line? > Other uses of this variable: >=20 > % optlen =3D sizeof(struct __msfilterreq); >=20 > The rvalue has type size_t. Unsigned is actually correct for size_t. > The lvalue has a smaller type in many cases and we need to know that > the result fits. We know that it is small, so if fits just as well > in an int as in an u_int. It is less clear that it fits in a = socklen_t > since that is supposed to be opaque. >=20 > % memset(&msfr, 0, optlen); >=20 > memset() takes a size_t for its 3rd arg, but any type that can = represent > the value works provided memset()'s prototype is in scope. >=20 > % err =3D _getsockopt(s, level, optname, &msfr, &optlen); >=20 > This use needs the correct type since the reference is indirect so the > prototype can't adjust the type. The arg had type "int *" in 4.4BSD > but has suffered from typedef poisoning so it is now "socklen_t *" > 4.4BSD also doesn't have socklen_t. socklen_t is specified by POSIX > as being an integer type with width at least 32 bits. It is not > required to be unsigned, and there are portability problems from this. > POSIX recommends that applications not store values larger than = 2**31-1 > in socklen_t. 2**31 would only work if it is unsigned. >=20 While locally the variable doesn=92t need to be unsigned, conceptually = it will never be less than zero. In this case, for the compiler, setting it to usigned int or to = socklen_t makes no difference. In practice changing it from signed to = unsigned has no effect either as the value will not be big enough to use = the extra bit. It=92s all just a waste of time I guess, so as I said, I won=92t MFC the = change. Pedro. =20