From owner-svn-src-head@freebsd.org Wed Jan 18 01:28:22 2017 Return-Path: Delivered-To: svn-src-head@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 0BE8ACB4DB6 for ; Wed, 18 Jan 2017 01:28:22 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4BE71AE8 for ; Wed, 18 Jan 2017 01:28:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x230.google.com with SMTP id l66so1133128ioi.1 for ; Tue, 17 Jan 2017 17:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y5x1as6yfqyhECSZEjdXx6nBJkv3EJi49p5JUv9xM/E=; b=JWmepxHIaURYFZsujZ08zV/ol4izuvcHF2KlbelULwFFAjXY8Wpx8Bl0aaKZHm7KMb SiOfJQgGc0iYLLD7gATJe+fWONuG0kDQFIIo54KcpUPHbtvVYOvfDSy+r1Z3zEGhOgQs lZnTdQtpRfK5LOILrWOdcKzGztmaKXv8zy2dgFET4BMsfXKwVcEZd0aIm7cDhdgWJ1ba EXGWs8hJbzcIjbPbCgS3I5GzaGi0dqHevx5YL8zDb3lp8seHbGOnPwTv7p71ThYT0EGn CuVPZqzs1khWTJYuSE8QfPBFbZFjktGLPA473Jeu/B5JIgOWV7wdg7NEnoKflmwTkLQ6 +dlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Y5x1as6yfqyhECSZEjdXx6nBJkv3EJi49p5JUv9xM/E=; b=iZWdjxtEbNh/i1U6t79g9bE2FwYaEqOJBBJBllDAXhEzOFVtZsFLYfFEYofWejyLQ9 j/OsBdlWTkj4kajpPXVcHEWOEBhwmzqf+iXTfb9DTA/g3yEa2hFg4AU9rGDOhSFbAb+A 9FUWtVZio5Bo2uzh3wi/2pcxoJ32PeAArTJfc7odsQGO8iBAeQ29wi7llg1F22R0FtxG 5wOUeVeiP2oEWcmR0119vzWs25hbGR+jR4IWf0LL2l4VEfh35FfNJzxW2QPB68bAki/z Whq7UQbQbUSbVMeZUDYzr47NpdQiNKWx7iobHnX/VOdXoXhLELN32wIjVqKstUOZybnq 7+eg== X-Gm-Message-State: AIkVDXKDoe80yc730WwJVfag3oCTR/3JndweXeu8Rdebn5echFi6AK2w9RuemPBvHkujc2We1EqvEAp1O8Yq4Dbi X-Received: by 10.107.18.230 with SMTP id 99mr1170735ios.45.1484702900866; Tue, 17 Jan 2017 17:28:20 -0800 (PST) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.160.66 with HTTP; Tue, 17 Jan 2017 17:28:20 -0800 (PST) In-Reply-To: <1484697145.86335.183.camel@freebsd.org> References: <201701161746.v0GHkcPX071529@repo.freebsd.org> <20170117065231.GW2611@FreeBSD.org> <20170117212713.GZ2611@FreeBSD.org> <1484697145.86335.183.camel@freebsd.org> From: Maxim Sobolev Date: Tue, 17 Jan 2017 17:28:20 -0800 X-Google-Sender-Auth: EPK6A-3fVOgkvQZV19A5kOTsWrM Message-ID: Subject: Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg To: Ian Lepore Cc: "Conrad E. Meyer" , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Wed, 18 Jan 2017 01:28:22 -0000 OK, guys, with all due respect I think I've heard enough to say that if somebody feels like this has to be enum feel free to jump in and tweak it out. As far as I understand there should be no user-visible differences either way, so it's not like we are going to be locked with this way forever. It's never too late to revise it (and it's FreeBSD-specific interface as well). Requesting me to implement something that it is at least a bit controversial and also something completely orthogonal to the original functionality and which I have no idea how to do/test properly on top of what's been done already is a bit overboard I would say. In my view, if we are to convert set/getsockopt(2) to enums it has to do in one shot and tested against large set of third-party software to make sure it won't bring out some corner cases (i.e. some unhandled values in switch() statements and the likes, C++ breakage, weird compilers, #ifdef blocks etc). If some developer(s) feel #define is an old way no longer relevant in 2017 the onus has to be on those to come up with a patch and go though the heat of defending it against other set of developers who don't share that opinion. Pushing me, who is largely ambivalent to either way, to do it is not fair. It's like asking mechanic who works on fixing your brakes to also paint your calipers for aesthetic reasons for the same price. Not even to mention that the change in question has been on reviews and received positive feedback from other developers working in the same area (e.g. gnn) and none of the enum guys paid any attention until it hit the tree. Also there is at least one thing that makes enum less desirable from the point of view of application developer. Particularly it makes it impossible to use preprocessor to do a conditional compilation, which is especially important for the FreeBSD-specific options. With the "old" way, I can easily have something like: #if defined(SO_TS_CLOCK) ... setsockopt(SO_TS_CLOCK, ...); #else [do something else] #endif This does not work with enums for obvious reasons, one would need to resort to using some kind of autoconfigure mechanism to figure out if the enum in question is defined. -Max On Tue, Jan 17, 2017 at 3:52 PM, Ian Lepore wrote: > I actually don't agree that it's all good, but I also don't have the > time to prove it's not (or prove myself wrong, which could certainly be > the case). > > -- Ian > > On Tue, 2017-01-17 at 15:21 -0800, Conrad Meyer wrote: > > Ian's potential objection has been met by Ben Kaduk and Eric van > > Gyzen's responses. It seems like an enum is just fine. And I agree > > with Gleb that it is preferable. > > > > Conrad > > > > On Tue, Jan 17, 2017 at 1:34 PM, Maxim Sobolev > > wrote: > > > > > > Well as other pointed out there are some concerns with using enums > > > from C++ > > > and ABI prospective. So it looks to me that there is no general > > > consensus on > > > that direction. > > > > > > -Max > > > > > > On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff > > > wrote: > > > > > > > > > > > > On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote: > > > > M> That being said, is there any other socket option value in > > > > there > > > > M> implemented as enum? I don't see anything obvious, so that I > > > > am curious > > > > if > > > > M> it would stick out as an odd one in there. What do you think? > > > > > > > > Simply because 30 years ago the language didn't allow that, and > > > > later > > > > additions mimiced the older sockopts. We need to break this loop > > > > :) > > > > > > > > -- > > > > Totus tuus, Glebius. > > > > > >