From owner-freebsd-sparc Mon Jan 13 0:59:30 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A52E37B405; Mon, 13 Jan 2003 00:59:27 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E66B743F65; Mon, 13 Jan 2003 00:59:25 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA10665; Mon, 13 Jan 2003 19:58:55 +1100 Date: Mon, 13 Jan 2003 19:59:30 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar Cc: Terry Lambert , Jake Burkholder , , Subject: Re: [PATCH] Re: fpsetmask on sparc64 In-Reply-To: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> Message-ID: <20030113190710.I11541-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 header (the other alternative was the > > 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 : I wouldn't like to see it moved. > The synopsis section of our manpage clearly states the inclusion > of . That header file includes a machine dependent > counterpart . On alpha, ia64 and sparc64 > is empty with the exception of the > inclusion of . > > Hence, I would like to see the prototypes and/or implementation > in . The prototypes are machine-independent, so they are correctly placed in . This has the technical problem that it is difficult to implement declared functions as inlines (*), so we use an ugly i386 ifdef in 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 > also includes , we should be able to move > the implementation on i386 to as well. If > possible, I'd like to see 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 ( is a BSDism AFAIK so other systems couldn't have anything there)... According to google, 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 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 as a primary interface on i386's only. It doesn't quite work on other arches since it doesn't include . - We implement as a link to to get the MD and implementation details right and the MI details wrong. Perhaps the broken ports include this and not . Then they would be less broken. - We also have 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-sparc" in the body of the message