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>