Date: Mon, 13 Jan 2003 12:45:05 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Bruce Evans <bde@zeta.org.au> Cc: Terry Lambert <tlambert2@mindspring.com>, Jake Burkholder <jake@locore.ca>, sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <20030113204505.GA798@dhcp01.pn.xcllnt.net> In-Reply-To: <20030113211536.E11945-100000@gamplex.bde.org> References: <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <20030113211536.E11945-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 13, 2003 at 10:21:59PM +1100, Bruce Evans 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. > > Hand-inlining things rarely makes sense, especially for little-used > compatibility-cruft functions like these. Aahh.. But by hand-inlining compatibility cruft, you remove them from the ABI! You only have them in the API, which is the lesser evil of the two when you want to remove the compatibility cruft completely. > A technical reason for not inlining some of them is that they may need > to interact with signal handling. I don't see how this is related. The only advantage of not inlining is the ability to declare the functions as weak so that they can be overridden. In all other cases it's just an implementation detail that should not affect the functionality. > We currently avoid most signal-handling > problems related to changing the FP environment by switching the critical > part of the environment in setjmp/longjmp, at least on i386's, but C99 > seems to forbid this. I think the functions that change the FP environment > need to save their setting somehwere so that longjmp() can restore the > default FP environment (not necessarily the one when setjmp() was called). > I don't know how to do this properly reentrantly. On ia64 the FP environment is callee saved and thus put in jmpbuf. The general modus operandi seems that functions either use the settings as inherited, or otherwise explicitly set them. This also applies to signal handlers. Thus when the FP environment is changed at function entry, the only action required is to restore the FP environment at function exit. > > 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... > > Non-inline versions are needed for at least calling functions through > function pointers if this is supported, and C requires it to be supported > for most functions including the ctype 1's. This requirement causes > some of the implementation complications in <ctype.h>. I see. Using static inline functions rather than macros should mostly solve this. Function pointer comparison will not work though, but I don't know if it has to. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030113204505.GA798>