Date: Wed, 17 Dec 2014 16:30:32 +0100 From: Ed Schouten <ed@80386.nl> To: Steve Kargl <sgk@troutmask.apl.washington.edu> 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: <CAJOYFBAAe_3psxdDC1Oq0%2BW=9T4qnSDK=tST3pP6q1iBpgME1w@mail.gmail.com> In-Reply-To: <20141216162055.GA64273@troutmask.apl.washington.edu> References: <201412160921.sBG9LvFY064961@svn.freebsd.org> <20141216162055.GA64273@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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. > 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. > 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? -- Ed Schouten <ed@80386.nl>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJOYFBAAe_3psxdDC1Oq0%2BW=9T4qnSDK=tST3pP6q1iBpgME1w>