Date: Mon, 13 Jan 2003 13:12:56 -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: <3E232BD8.234FA1B4@mindspring.com> References: <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <20030113211536.E11945-100000@gamplex.bde.org> <20030113204505.GA798@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > > 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. This does not apply in this case, since the inlined function is not itself making a system call that could be interrupted by a signal. This argument only applies in the case where the inlined function makes a system call, and the default behaviour is not SA_RESTART. > > 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. This is a valid argument, but we are not really here to fix the lack of an i386 prototype in scope in the case that inilining is disabled, any more than we are here to fix the fact that everything goes to hell if the #ifdef for "GNUC" fails because another compiler is being used. The prototypes are out of scope in the non-inline case, but the #define's are not. I don't know the correct compiler voodoo to make the #define's go away when inlining is disabled, the way the inline functions themselves do (maybe Bruce can help out here). The other issue is that there are not i386 implementations for these functions in /usr/src/lib/libc/i386/gen, at this point, so you would either need to pull the code in from NetBSD/OpenBSD, or you would need to have a .c file that forces the inlining with stub instances, including the machine dependent header file. To my mind, this is a problem to address *after* the 5.0 release; one hopes that the ports compilation issues will be addressed *before* the 5.0 release. One also hopes that the *way* they are addressed will be to make the ports *work* on IA64, SPARC, and Alpha, rather than making them *break* on i386. Consistent behaviour is not a good thing, if it's consistently *bad*... 8-) 8-). -- Terry 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?3E232BD8.234FA1B4>