On Mon, 2020-05-18 at 23:01 +0200, Michael Tuexen wrote: > > On 18. May 2020, at 22:48, Ian Lepore <i...@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 complain about the change, because to me it reduces rather than improves code quality. -- Ian _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
