Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 2003 10:31:26 +0100
From:      Atle <trollet@skynet.be>
Cc:        sparc@FreeBSD.ORG
Subject:   Re: [PATCH] Re: fpsetmask on sparc64
Message-ID:  <3E23D8EE.DDA28DBB@skynet.be>
References:  <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <3E2324B0.585FD417@mindspring.com> <20030113210642.GB798@dhcp01.pn.xcllnt.net> <3E232F9C.D323FF99@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:

> Having <floatingpoint.h> on SPARC makes sense, in terms of being
> able to support a *legacy* interface for *legacy* code that needs
> it.  Both uses of the word "legacy" are important here.  I think
> that the header file should complain, during compilation, when it
> is used, e.g.:
> 
> #warning "this file includes <floatingpoint.h> which is obsoleted, use
> <ieeefp.h> instead"
> 
> This doesn't contradict uniformity across platforms, per se,
> since the interface is deprecated.
Please excuse an ignorant fool for barging in, I have been following
this, taken a step back, and concluded 'this is not easy to follow'.
I often consult my wife when I have design problems, so I will be the
'wife' here.
I try as far as possible to let names be uniform across declaration (.h
files) and libraries (.a .o .so).
So if a program does this
#include <foo.h>
then it links with something called foo.o or libfoo.a
Anything that depends on i386 lives inside some

#ifdef i386
#include <386quirks.h>
#else
#include <some_stubs_for_undeclarations.h>
#endif

Is there a fundamental design issue here?
If there is even a change that some circular #includes can happen, then
surely there must be something wrong?

Please ignore this if it is irrelevant,

Atle
http://atle.linux-site.net

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E23D8EE.DDA28DBB>