Date: Mon, 13 Jan 2003 12:42:24 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Bruce Evans <bde@zeta.org.au>, Jake Burkholder <jake@locore.ca>, sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <3E2324B0.585FD417@mindspring.com> References: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> <20030113100558.GA3423@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > This part is what makes me opt for moving the prototypes to the > MD header. These functions are trivial most of the time that > inlining them makes sense. I don't see why other platforms can't > or won't inline in the future. I think so, too, but it depends on the hardware. > What about signaling the MI header about the existence (or non- > existence) of inline functions and/or macros in the MD header so > that the MI header can optionally provide the prototypes? This > can be done by having the MD header define (or undefine) some > macro (or set of macros). This would be a Bad Thing(tm). Specifically, it would throw some namespace pollution into the implementation space, which is not something that should be permitted, I think. > Also, it appears to me that we always have to provide non-inlined > versions in libc for when inlining is disabled. See ctype.h. > I may misinterpret the comment though... No, this is true. There is also a problem with the "GNUC" tests in the inilining definitions, particularly, since there is a cdefs.h in scope, and there's a portable way to get rid of the "GNUC"-isms. > Am I right when I say that removing floatingpoint.h (both the MD > file and the MI link) will fix the port, independent of how we > shape ieeefp.h? IMO, no. The port will remain broken. Kris is the person to ask on this, actually, since he's the one who reported the problem, initially. > > - We implement <floatingpoint.h> as a link to <machine/floatingpoint.h> > > to get the MD and implementation details right and the MI details wrong. > > Perhaps the broken ports include this and not <machine/floatingpoint.h>. > > Then they would be less broken. > > Some configure scripts may check for <floatingpoint.h> for compatibility > with SunOS/Solaris. I doubt they will check <machine/floatingpoint.h> And here's the reason why. The SPARC platform for FreeBSD will need to be sensitive to the fact that people will port from SPARC running some other OS to SPARC running FreeBSD. The most likely source of ported code in this case is SPARC running Solaris, which has the header file in question. > In summary: I like Terry's second patch but am sensitive to having > the MI prototypes in <ieeefp.h> as well as allowing inlining. > What about something like the following to keep the prototypes in > <ieeefp.h>, but still allow inlining (in combination with Terrys > patch): This is a patch post-application of my patch; you are missing the floating point function prototypes in the non-inlined case. 8-). But it's fixable. I personally worry about putting stuff into the namespace that people might then key off of when doing ports or other work, in order to let them use FreeBSD-isms. I'm particularly sensitive on this point, because I personally abused the PTHREAD_MUTEX_INITIALIZER to distinguish between draft 4 and standard implementations, and then that was the first thing that they added going from draft 4 to standard, without implementing all of the rest of the standard first. 8-(. This broke a lot of pthreaded code that I worked on and threw the patches back to the maintainers, including MySQL, OpenLDAP, ACAP, and anything statically declaring the mutex-using classes that implement using threads in the C++ STL code out of MCSCA. It was a real mess when FreeBSD made that change. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E2324B0.585FD417>