Date: Mon, 18 May 2020 23:57:00 +0200 From: Michael Tuexen <tuexen@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: cem@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r361209 - head/sys/netinet Message-ID: <99D6D374-B8C6-4D47-812A-6DA5740DDDE9@freebsd.org> In-Reply-To: <90bc5fc67941a0b3ad8235351cfc303dc3a37c40.camel@freebsd.org> References: <202005181007.04IA713t089936@repo.freebsd.org> <CAG6CVpWA1gKLzacDeAFOGTKJcNrg608k5yu8CJg48_WFS0omnA@mail.gmail.com> <E8554788-B6CD-44A9-8ABF-7F3CD129F87F@freebsd.org> <CAG6CVpU3QpCr9WVsuc1eRJrEV3XuQEWGHRCZ9FHMmRmB2N67Mg@mail.gmail.com> <064C2DCD-6279-4442-A900-0ECCD50CC4FA@freebsd.org> <CAG6CVpVrJE7hnEeGxzeBMUEWsi_N2EtGXdH8ZbZbEQ0GtnDovw@mail.gmail.com> <ED7C6ECA-23E4-43D9-B08D-2A39027FC210@freebsd.org> <124078163fc75e82a0acaff85f57859d012c6d98.camel@freebsd.org> <58B8E5E9-8DA1-4453-B1A3-A90D97D5FD43@freebsd.org> <90bc5fc67941a0b3ad8235351cfc303dc3a37c40.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 18. May 2020, at 23:09, Ian Lepore <ian@freebsd.org> wrote: > > On Mon, 2020-05-18 at 23:01 +0200, Michael Tuexen wrote: >>> On 18. May 2020, at 22:48, Ian Lepore <ian@freebsd.org> 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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99D6D374-B8C6-4D47-812A-6DA5740DDDE9>