From owner-freebsd-net@freebsd.org Thu May 5 00:23:34 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DAC7B2BCC8 for ; Thu, 5 May 2016 00:23:34 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3ADE21B0D for ; Thu, 5 May 2016 00:23:33 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from blue.beer.town (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 61043564B8; Wed, 4 May 2016 19:23:27 -0500 (CDT) Subject: Re: setsourcefilter/getsourcefilter missing const qualifier? To: Victor Toni , freebsd-net@freebsd.org References: From: Eric van Gyzen Message-ID: Date: Wed, 4 May 2016 19:23:26 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 00:23:34 -0000 On 05/ 3/16 03:50 PM, Victor Toni wrote: > When trying to compile some linux-originated code on FreeBSD I get the > following errors: > > /usr/include/netinet/in.h:585:5: note: candidate function not viable: 3rd > argument ('const sockaddr *') would lose const qualifier > int setsourcefilter(int, uint32_t, struct sockaddr *, socklen_t, > ^ > /usr/include/netinet/in.h:587:5: note: candidate function not viable: 3rd > argument ('const sockaddr *') would lose const qualifier > int getsourcefilter(int, uint32_t, struct sockaddr *, socklen_t, > ^ > > the main difference is that the linux version makes guarantees about > the parameters. > > > Wouldn't it be safe for the FreeBSD version to make the same assumption? Yes, it would be safe in practice, since the implementation does not modify those parameters. However, RFC 3678 does not specify them as const, and neither do illumos (Solaris) and Mac OS X, so code that tries to pass const parameters is not portable. I would suggest changing the code to pass non-const parameters. Eric