Date: Mon, 13 Jan 2003 19:59:30 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@xcllnt.net> 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: <20030113190710.I11541-100000@gamplex.bde.org> In-Reply-To: <20030113034638.GA2310@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Jan 2003, Marcel Moolenaar wrote:
> On Sun, Jan 12, 2003 at 06:27:00PM -0800, Terry Lambert wrote:
> >
> > Therefore, it seems to me, that the correct place to put them is in
> > the <machine/floatingpoint.h> header (the other alternative was the
> > <machine/ieeefp.h> header; this seemed wrong to me, but I'm willing
> > to reroll the patch, if there's a lot of disagreement over this point).
>
> I would like to see it in <machine/ieeefp.h>:
I wouldn't like to see it moved.
> The synopsis section of our manpage clearly states the inclusion
> of <ieeefp.h>. That header file includes a machine dependent
> counterpart <machine/ieeefp.h>. On alpha, ia64 and sparc64
> <machine/floatingpoint.h> is empty with the exception of the
> inclusion of <machine/ieeefp.h>.
>
> Hence, I would like to see the prototypes and/or implementation
> in <machine/ieeefp.h>.
The prototypes are machine-independent, so they are correctly placed
in <ieeefp.h>. This has the technical problem that it is difficult
to implement declared functions as inlines (*), so we use an ugly
i386 ifdef in <ieefp.h> to prevent them being declared. This seems
least evil since inlining them doesn't seem to be useful and the
wart only affects i386's, and these functions should be obsoleted
by the C99 functions as soon as possible.
%%%
(*) The folling implementations don't work:
(1)
int foo(int x);
static /* inline */ int foo(int x) { return x; }
This is not conforming C IIRC. TenDRA says:
"z.c", line 2: Warning:
[ISO 6.1.2.2]: 'foo' previously declared with external linkage (at line 1).
(Since this is only a warning, I'm not sure that it is an error.)
(2)
static /* inline */ int foo(int x) { return x; }
int foo(int x);
This is conforming C, but "helpful" compilers warn about it with certain
warning flags:
z.c:2: warning: redundant redeclaration of `foo' in same scope
z.c:1: warning: previous declaration of `foo'
%%%
> Since on i386 <machine/floatingpoint.h>
> also includes <machine/ieeefp.h>, we should be able to move
> the implementation on i386 to <machine/ieeefp.h> as well. If
> possible, I'd like to see <machine/floatingpoint.h> retired
> unless there's a compelling reason to keep it...
There is no good reason for these to be separate, but they may be
required for compatibility. IIRC, their names and interfaces were
copied from some system (Sun) that had them, but they were slightly
misplaced (<machine> is a BSDism AFAIK so other systems couldn't have
anything there)... According to google, <floatingpoint.h> was in
/usr/include in SunOS in 1992 (we link it there), and it seems to
be the primary interface (Sun apparently had ieeefp.h in <sys> then,
but non-BSD hits on it are not as common.
So we seem to have headers half compatible with at least the old version
of SunOS that they attempt to be compatible with:
- We have <floatingpoint.h> as a primary interface on i386's only. It
doesn't quite work on other arches since it doesn't include <ieeefp.h>.
- 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.
- We also have <ieeefp.h> as a primary interface which works on all arches,
and our man pages say to use this.
- Applications can easily shoot there feet off by stepping into this header
tangle in any place except the one that is actually docuemented under
FreeBSD.
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?20030113190710.I11541-100000>