> 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 > _______________________________________________ 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"
