On 17 December 2014 at 07:30, Ed Schouten <e...@80386.nl> wrote: > Steve, > > 2014-12-16 17:20 GMT+01:00 Steve Kargl <s...@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?
Actually, the fact that the MD5 signature changed means that the binary code generated has changed, and thus it "isn't harmless." It may be, but it certainly didn't generate identical binary code. We have some active and interested math nerds involved; perhaps a drive-by shooting without including them should be avoided. -adrian _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
