From owner-svn-src-all@freebsd.org Mon May 18 21:57:04 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BAEA72DEB3E; Mon, 18 May 2020 21:57:04 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49QtCN3BCNz4Rd0; Mon, 18 May 2020 21:57:03 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mbp.fritz.box (ip4d1600c4.dynamic.kabel-deutschland.de [77.22.0.196]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 1FBBE7220F40F; Mon, 18 May 2020 23:57:01 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r361209 - head/sys/netinet From: Michael Tuexen In-Reply-To: <90bc5fc67941a0b3ad8235351cfc303dc3a37c40.camel@freebsd.org> Date: Mon, 18 May 2020 23:57:00 +0200 Cc: cem@freebsd.org, src-committers , svn-src-all , svn-src-head Content-Transfer-Encoding: 7bit Message-Id: <99D6D374-B8C6-4D47-812A-6DA5740DDDE9@freebsd.org> References: <202005181007.04IA713t089936@repo.freebsd.org> <064C2DCD-6279-4442-A900-0ECCD50CC4FA@freebsd.org> <124078163fc75e82a0acaff85f57859d012c6d98.camel@freebsd.org> <58B8E5E9-8DA1-4453-B1A3-A90D97D5FD43@freebsd.org> <90bc5fc67941a0b3ad8235351cfc303dc3a37c40.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 49QtCN3BCNz4Rd0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 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: Mon, 18 May 2020 21:57:04 -0000 > On 18. May 2020, at 23:09, Ian Lepore wrote: > > On Mon, 2020-05-18 at 23:01 +0200, Michael Tuexen wrote: >>> On 18. May 2020, at 22:48, Ian Lepore wrote: >>> >>> On Mon, 2020-05-18 at 22:43 +0200, Michael Tuexen wrote: >>>>> Sure. You can certainly ignore user reports corresponding to >>>>> bogus >>>>> flags, though, and encourage use of various flags. >>>> >>>> I could, but decided to improve the situation for some people, >>>> but >>>> wasn't realising that I made it worse for others. Sorry about >>>> that. >>> >>> I'm trying to figure out why your original commit was a problem. I >>> understand why it was questioned, but once the answer came out, >>> it's >>> clear that the code you originally committed does what it's >>> supposed to >>> without any harmful side effects. Sure, freebsd doesn't strictly >>> need >> >> I guess the point Conrad is making, that on FreeBSD the check is not >> needed, since the call can not fail. So the FreeBSD code base would >> not >> be consistent: within the SCTP related code the return code is >> checked, >> in the other code it is not. >>> it, but the code is shared among projects, so what's the harm in >>> the >>> extra check that helps other projects sharing the code? It's >>> certainly >>> a lot less confusion and code clutter than any of the "remedies" >>> that >>> have been discussed. >> >> Yepp, sharing code between platforms makes things harder. Running the >> same >> code in kernel land and userland does not make it simpler. Different >> groups >> have different opinions/styles/... >> >> I'll revert the commit tomorrow and a variadic macros >> SCTP_SNPRINTF(), which >> will map on FreeBSD to snprintf() and on the other platforms will do >> the check. >> >> If the build problem comes up on FreeBSD userland (and I have no idea >> if that >> is the case, since I don't know how Firefox / Chrome are build on >> FreeBSD), >> I leave it up to the port maintainer of the application to deal with >> it. >> >> Best regards >> Michael >>> >>> -- Ian >>> >> >> > > Well it seems to me you're being asked to do a lot of extra work that > has the final result of making the code LESS clear and MORE complex, > because of one person's opinion. I'm actually a bit tempted to Yes, it is one person. But it is one person who thinks the change is bad enough that he needs to speak up. So I think this has to be addressed. > complain about the change, because to me it reduces rather than > improves code quality. Well, we have abstracted from FreeBSD specifics by using macros in other cases as well. Adding another macro will make reading a bit harder and you have to lookup the platform specific implementation of the code to figure out what is going on, but that way, I guess, people will get a result they can live with. Best regards Michael > > -- Ian > >