From owner-svn-src-all@FreeBSD.ORG Sat Jul 19 14:45:24 2014 Return-Path: Delivered-To: svn-src-all@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 A0447E41 for ; Sat, 19 Jul 2014 14:45:24 +0000 (UTC) Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) (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 425F2219C for ; Sat, 19 Jul 2014 14:45:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1405780782; bh=zvOkwxffsFhnrpnRkkGXIOG6uc7n9ny6Cj1OwcO4uo4=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EXHeR+++pGjqTV/feCM9qyZPWsQMlnqlPXZ8dtFSKeyP0zBKewnyahMe/b9Hk1CbyiKctGkzClV0fO/JOyBG8jD6LU3eA7lBn5HezZD5ubApR+L3Vo7aysG+bFatmMRAKpo2mFBxgmrGSHwuHbYT1T1VurGTKjScc37cRBJEz5rmXTjTJQ1XMfUbE9xjm5t6aEfu7KiMqnZX/SCo6hsbuzgBwheVFFAOnqa1m3OP+Q8oOkknKCkHOni96Ox8+mwLoV++CkTkfj9R23TCzmBeSYuP7J4uakNLpdiXqnlH3UGd4ImDRiXCytF6v494YbLX1dtDJxWJgjnKt+KzDMy1kg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=N1dpRaUBEwv3K5RquNNtBZGyDYcJZ8ZDINNXcHPj7qpbuCzDSr9k003xw82jl/Id8EgGi1AGP0IOX72dAso1HY/NTRFDezF5DKtIES4/nDB+Fxa6qq3lKXJGmgnABfIhCWRgx1mU4UZLn2HUp6Z+CKamSGvITtorZLLcoihhVRThID3IYcHWJ3CLT/hq51l4DJGV9wCkf3fTXmEarRZ2WQ5nSGNfGldQ4g4YIT/tPWMBBjmgp2dD/lUxOQo+Pn4+XkQ8VE7IFVsBGukpDs/gaIr0Cg+a0bvxYdG5n6jG0YLUFNOLdODXkGYifW7+HBXE+tcMjptqgh4uoZHgM7oCKw==; Received: from [66.196.81.174] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jul 2014 14:39:42 -0000 Received: from [98.139.213.15] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jul 2014 14:39:42 -0000 Received: from [127.0.0.1] by smtp115.mail.bf1.yahoo.com with NNFMP; 19 Jul 2014 14:39:42 -0000 X-Yahoo-Newman-Id: 727504.65074.bm@smtp115.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kJLmnDEVM1krQS6yQlYP6TtvJai.q12AArD5iI7pcRdULOA XcN5FloezKvzP8Ae7z1_nlS.blKnnv7pK2UN0uDoxxpHWbnpPKMUgNgDgj9j w57Fs1uNNttgla6qkY176gEgkUhL.guJY_7TSIEUjYkRp0OnNshfYXVE95RU HK95Hxz_LI0929cMB4om17op56ByUnDKT.JgyK29S9nnjAKPPHYCCztilAZw mOrLE8YpD6YNwRG9MC_9GLyGXFLSKgpT1JpBe4CHPgnv2ko3A.vuPq0FZSoc wdUcmCav_91_OEe5gspB.mALI5ENBQN7k_j5Ns5ba9o02M4r11QoVGV00pr9 nRwUL.tSCPPNyw7rM0VtU1Bm3ERIFI0rIVOxw19nbabbW143SKvlaJX25mou QPSgmrAjTaY42wLRiWp0NKlv9ZVUvQ0nZLKreP9ctTe.qAwPn47zMUd5t_kE BrZJ5rDs6e_jMO9BrKj2arqlT.G59xoy8J8BA0omn59F9dLDdMAfTbghkUe1 1fIX0tObW8h2CnzV_B8fLzEUIKb4- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <53CA8332.2060507@freebsd.org> Date: Sat, 19 Jul 2014 09:39:46 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bruce Evans Subject: Re: svn commit: r268867 - head/lib/libc/net References: <201407190153.s6J1rqBn027367@svn.freebsd.org> <20140719171552.W874@besplex.bde.org> <20140719210009.O1782@besplex.bde.org> In-Reply-To: <20140719210009.O1782@besplex.bde.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 14:45:24 -0000 On 07/19/14 06:29, Bruce Evans wrote: > On Sat, 19 Jul 2014, Pedro Giffuni wrote: > >> Il giorno 19/lug/2014, alle ore 02:36, Bruce Evans >> ha scritto: >> >>> On Sat, 19 Jul 2014, Pedro F. Giffuni wrote: >>> >>>> Log: >>>> Use unsigned optlen in getsourcefilter() >>>> >>>> Sizes can not be negative and the functions that use it >>>> expect an unsigned value anyways. >>>> >>>> Obtained from: Apple (Libc-997.90.3) >>>> MFC after: 1 week >>> >>> 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. >>> >> >> Ah, yes, we have had this discussion before � in relation with ext2fs >> ;). > > Yes, it caused bugs in practice there. > >> The compiler doesn�t have a way to tell if socklen_t is of a certain >> type "by accident�. > > Yes, this is a fundamental problem with C typedefs -- they are too > similar > to their underlying type. > > Any size error would be detected more reliably than the sign error in > furture when int is expanded by socklen_t stays 32 bits. Except the > assumptions that int is 32 bits is even more established now than it > was on vaxes, so no one would expand int. > >> 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. >> >> >>>> Modified: >>>> head/lib/libc/net/sourcefilter.c >>>> >>>> Modified: head/lib/libc/net/sourcefilter.c >>>> ============================================================================== >>>> >>>> --- 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; >>> >>> This has mounds of style bugs. 2 more now (unsorting, and not using >>> u_int, except u_int is not just a style bug) >> >> While aesthetically it may be better to keep the sorting, it doesn�t >> seem correct to preserve it at the expense of setting the incorrect >> type. Would you really want me to set optname in another line? > > You already had to change the sorting to split the declaration. When > changing, it is better to put things in their correct place directly. > u_int is sorted before int because it is a more complex type with a > higher rank. socklen_t is sorted before int because it is a more > complex type with an unknown (opaque) relative rank. > Ugh.. wish they taught these type of things in books ... Hopefully I got it right this time ;). Thank you.