svn commit: r361209 - head/sys/netinet

Michael Tuexen tuexen at freebsd.org
Mon May 18 21:01:17 UTC 2020


> On 18. May 2020, at 22:48, Ian Lepore <ian at 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
> 



More information about the svn-src-all mailing list