Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 2003 10:05:31 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
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
Message-ID:  <20030114095915.C14524-100000@gamplex.bde.org>
In-Reply-To: <3E2321CF.A5835FCD@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030114095915.C14524-100000>