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

[Maxim Sobolev]

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 <ian at freebsd.org> 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 <sobomax at freebsd.org>
> > 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 <glebius at freebsd.org
> > > > 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.
> > > >
>
>