From owner-freebsd-sparc  Mon Jan 13 15: 8:19 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 C5E7F37B401; Mon, 13 Jan 2003 15:08:17 -0800 (PST)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id ECCCA43E4A; Mon, 13 Jan 2003 15:08:15 -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 KAA07448;
	Tue, 14 Jan 2003 10:04:51 +1100
Date: Tue, 14 Jan 2003 10:05:31 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Jake Burkholder <jake@locore.ca>, <sparc@FreeBSD.ORG>,
	<current@FreeBSD.ORG>
Subject: Re: [PATCH] Re: fpsetmask on sparc64
In-Reply-To: <3E2321CF.A5835FCD@mindspring.com>
Message-ID: <20030114095915.C14524-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: <freebsd-sparc.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-sparc>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-sparc>
X-Loop: FreeBSD.org

On Mon, 13 Jan 2003, Terry Lambert wrote:

> Bruce Evans wrote:
> > On Sun, 12 Jan 2003, Terry Lambert wrote:
> > > This patch also affects the IA64 and Alpha, as well as just the SPARC.
> > >
> > > It took a lot of discussion, but it seems to me that the problem is
> > > that the prototypes in scope aren't in scope when the wrong include
> > > file is included.
> >
> > Right.  It is mainly an application bug like I said.  The prototypes
> > also aren't in scope when <stdio.h> is included, and the fix is not
> > to add them to <stdio.h>.
>
> I really disagree.  A legacy application *can't* be said to be
> buggy.

Depends how legacy.

> There has to be some allowance for the continuity of code; it
> can't just be orphaned instantaneously, without some warning
> from the system vendor.

A warning was given here more than 4 years ago:

% RCS file: /home/ncvs/src/include/ieeefp.h,v
% Working file: ieeefp.h
% head: 1.6
% ...
% ----------------------------
% revision 1.1
% date: 1998/12/23 11:50:52;  author: dfr;  state: Exp;
% branches:  1.1.2;
% Implement fpsetmask() and other fp*() functions.  Programs should use
%
% 	#include <ieeefp.h>
%
% to access these functions instead of the i386 specific
%
% 	#include <machine/floatingpoint.h>
%
% Submitted by: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
% ----------------------------

> Say we took your approach, and moved the #define's for the inlines
> up into <ieeefp.h>, exposing platform dependencies in a (supposedly)
> platform independent header file.  How many ports would break?  All

Not my approach.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-sparc" in the body of the message