svn commit: r361209 - head/sys/netinet

[Michael Tuexen]

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