Date: Wed, 17 Dec 2014 11:12:35 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Ed Schouten <ed@80386.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r275819 - in head/lib/msun: ld128 ld80 src Message-ID: <20141217191235.GA89501@troutmask.apl.washington.edu> In-Reply-To: <CAJOYFBAAe_3psxdDC1Oq0%2BW=9T4qnSDK=tST3pP6q1iBpgME1w@mail.gmail.com> References: <201412160921.sBG9LvFY064961@svn.freebsd.org> <20141216162055.GA64273@troutmask.apl.washington.edu> <CAJOYFBAAe_3psxdDC1Oq0%2BW=9T4qnSDK=tST3pP6q1iBpgME1w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 17, 2014 at 04:30:32PM +0100, Ed Schouten wrote: > Steve, > > 2014-12-16 17:20 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>: > > This seems like a lot of code churn for very little benefit. > > > > In particular, I know that the one person working on fixing > > problems with FreeBSD's libm has a private repo and the openlibm > > and android developers base their libm off of FreeBSD's libm > > and now they'll need to resync their codebases and resolve > > conflicts. > > I'm always afraid of statements like these, as they can be brought to > the table to prevent any changes from being made. The fact that > someone else (be it Android or openlibm) uses our code should not > limit us as a project to make changes. Hopefully this change will > merge into their direction as well? I stand corrected. Foisting unnecessary code churn on others is now an acceptable practice. > The fact that we often do not dare to refactor our code is exactly > what puts us in the spot that a lot of our code is often not directly > reusable by others, needs to be forked and adjusted. Examples include > u_intX_t, bcopy(), etc. Your refactoring is nothing more than a gratuitous code change. The reasons you give in your commit log are bogus justification. But the damage is done. Asking you to revert the patch would simply be more code churn. > > This comment isn't true! These functions pre-date C11 by years. > > See r151865. These functions were designed to deal with gcc's > > poorly implemented I. See the paragraph above your comment. > > Keep in mind that the phrasing is intended to say that CMPLX*() and > friends are part of C11. Those do not pre-date C11. The phrasing is wrong. cpack[fl] came at least 6 years before C11 and were designed to work around defects in C99. CMPLX[FL] were introduced into C11 to address those defects. Changing cpack[fl] to CMPLX[FL] and claiming that the functions are modeled after the C11 macros is wrong (unless the meaning of "before" and "after" have changed). > > Upon further inspection with md5, this change affects only a single > > file. This last paragraph appears to be an excuse for a drive-by > > commit. > > But also acts as proof that the change is harmless. I am not entirely > sure what you're trying to imply with this. Are changes that do not > affect checksums of object files are bad? Gratuitous changes are well gratuitous. You are causing extra work for people actively working on libm and other projects that use FreeBSD's libm. The fact that I ran md5 over the *.o files suggests that you made the change without even checking on its effect on the resulting library. To be blunt, your patch has/had ZERO BENEFIT at the expense of causing additional work for others. There are ample opportunities to improve libm. powl, tgammal, j0l, j1l, jnl, y0l, y1l, ynl, and number of the long double complex functions are not implemented. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141217191235.GA89501>