> On 18. May 2020, at 23:09, Ian Lepore <i...@freebsd.org> wrote: > > 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 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 > > _______________________________________________ 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"