Date: Mon, 13 Jan 2003 07:48:56 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Kris Kennaway <kris@obsecurity.org>, <sparc@FreeBSD.ORG>, <current@FreeBSD.ORG> Subject: Re: fpsetmask on sparc64 Message-ID: <20030113072350.R8829-100000@gamplex.bde.org> In-Reply-To: <3E217111.B3C4C512@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Jan 2003, Terry Lambert wrote: > Bruce Evans wrote: > > On Sun, 12 Jan 2003, Terry Lambert wrote: > > > Bruce Evans wrote: > > > > > Is this an omission, or are the ports wrong? > > > > > > > > First answer: > > > > This is a bug in the ports. The non-i386 arches are apparently including > > > > <machine/floatingpoint.h> instead of the documented interface <ieeefp.h>. > > > > > > Wow, gotta disagree with that; the problem doesn't magically go > > > away when you include the standard header file. > > > > Yes it does (should). > > We're at cross-purposes here, I think. It doesn't go away, even if > it should; here's ieeefp.h: > > #ifndef _IEEEFP_H_ > #define _IEEEFP_H_ > > #include <sys/cdefs.h> > #include <machine/ieeefp.h> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here are the manifests (sic). > > #ifdef __i386__ > #include <machine/floatingpoint.h> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here is i386-specific code (which happens to be the implementation of the functions as inlines). > #else /* !__i386__ */ > __BEGIN_DECLS > extern fp_rnd_t fpgetround(void); > extern fp_rnd_t fpsetround(fp_rnd_t); > extern fp_except_t fpgetmask(void); > extern fp_except_t fpsetmask(fp_except_t); > extern fp_except_t fpgetsticky(void); > extern fp_except_t fpsetsticky(fp_except_t); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here are the declarations of the functions. These are used by the arches that don't implement them as inlines (which happen to be all non-i386 arches). Here are also some style bugs (extern, and no tabs). > __END_DECLS > #endif /* __i386__ */ > > #endif /* _IEEEFP_H_ */ > > The function will still be missing from the library, even if there's > a valid prototype in scope, because you included the header file, and > didn't get any of the manifests. To get the manifests, you have to > include the <machine/ieeefp.h>, seperately. The functions are not shown above. They are normal functions in libc for most arches. > Notice that the only real difference is whether or not the > operations end up using an inline version of the functions, or > expect one to be in the library. > > That's a library bug, that they would not be implemented on SPARC. They aren't implemented as inline functions on sparc64's, so no amount of header inclusion can do more than declare them. Including wrong headers result in them being completely undeclared. > ... > > > > I think the ports are only meddling the FP mask to hide their FP errors > > > > when running under FreeBSD-3.x and earlier anyway. > > > > > > They are meddling with it because the FreeBSD default, while it is > > ^^ iswas (1) > > > permitted by the standard, is different from what most software > > was (2) > > > expects the default to be. > > > > (1) was permitted by C90; is not permitted by C99, but C99 is not supported > > yet. > > So it's irrelevent, right? It's probably irrelevant. I haven't looked at the ports. They seem to attempting to make null changes in FreeBSD-4.0 and later. > > (2) was different before FreeBSD-4.0. Are there any ports that still > > support FreeBSD-3? > > Not this software, certainly... making it also irrelevent, right? Not quite irrelvant, since they seem to have dead code which has been wrong since 1998. > > > Yeah, it'd be nice if it weren't there, but the man page itself > > > specifically uses fpsetmask() in an example (to prevent some trap). > > > > The man page still supports FreeBSD-3 :-). It is version-agnostic. The > > default setting is very MD, so software that actually cares must not > > assume anything about the defaults. > > Exactly. And therfore must call the function to set the FPU into > a known state, with regatd to exception handling, etc.. Which > makes my case, there. Very few applications have a legitimate use for doing this. I would expect the ones that do to know which headers to include. > ... Bruce 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?20030113072350.R8829-100000>