Date: Mon, 13 Jan 2003 12:24:31 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce Evans <bde@zeta.org.au> Cc: Marcel Moolenaar <marcel@xcllnt.net>, Jake Burkholder <jake@locore.ca>, sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <3E23207F.A889A410@mindspring.com> References: <20030113190710.I11541-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > The prototypes are machine-independent, so they are correctly placed > in <ieeefp.h>. This has the technical problem that it is difficult > to implement declared functions as inlines (*), so we use an ugly > i386 ifdef in <ieefp.h> to prevent them being declared. In fact, this is exactly the problem. The correct thing to do is to ensure that the values come into scope at the same level in all implementations. Effectively, this means that the #define's for the i386 version's inline references need to be at the same level as the prototype declarations. Where the prototype declatations take place is actually moot. > 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. I think it is better to fully adhere to an old standard than to partially adhere to a new one. FreeBSD was much better off, in terms of software portability, when it supported the full Draft 4 pthreads standard (both Jeremy Allison and I had a hand in the final work of making it conform), than it was when it was in partial conformance to the new standard. Whether or not inlining them should be ripped out in favor of real library routines, as in OpenBSD and NetBSD, is another matter, and, as far as I'm concerned, that's off the table for discussion at this point. I'm unwilling to change implementation this late in the game, only organization. No matter how you look at it, the code should be organized such that including the same header files, *whatever* they are, ends up with the same results on all flavors of FreeBSD. Riht now, that does not happen. Both of the proposed patches fix this. Another way of fixing this would be to move the #define's for the inline versions *up* into /usr/include/ieeefp.h, so that the scope comes from there. This is consistant with your suggestion here. There are two reason to not do this, at this point: 1) It will cause some ports to be broken; arguably, these ports *should* be broken. But when you complain about them, you are really complaining that the <machine/XXX.h> scope is visible to user programs directly, instead of forcing them to include the correct header files, instead. I think this complaint should be addressed in the compiler, and can be, by having a #pragma that maches the directory visible to the compiler, with the default being invisible, and the regular headers can set the #pragma, and third party code can break. I would argue that, whatever you do to address the complaint, however, you address it *later*. 2) This approach has the negative effect of leaving platform variant code in a system header file. This is, in my opinion, and incredibly broken thing to do, even if you ignore all other issues. If you are dead set on this approach, I can provide a patch that will move the i386 #define's from <machine/floatingpoint.h> up into <ieeefp.h>; but I believe this is bad design at its worst. > > Since on i386 <machine/floatingpoint.h> > > also includes <machine/ieeefp.h>, we should be able to move > > the implementation on i386 to <machine/ieeefp.h> as well. If > > possible, I'd like to see <machine/floatingpoint.h> 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 (<machine> is a BSDism AFAIK so other systems couldn't have > anything there)... According to google, <floatingpoint.h> 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 <sys> then, > but non-BSD hits on it are not as common. I agree that floatingpoint.h is probably something that should gracefully fall into compatability, in terms of a message that says "deprecated; include XXX instead"; FreeBSD already has a number of these. But in any case, this is not really a functional issue, and I really don't care about it. 8-). > - 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. This is the case as it is today. The patches I have proposed, both reattach the feet of a number of application in ports, based on them already having stepped in this mine field. I think it's not reasonable to believe that you can make people rewrite all the old code in the world to conform to new standards (e.g. C99, etc.). Basically, this means to me that a successful standard is not one which tries to change how things are done, but instead permits legacy code to continue to function. This *also* argues for pushing the declaration scope for these things down, instead of pulling them up into the (supposedly) machine independent headers. -- Terry 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?3E23207F.A889A410>