Date: Wed, 30 Jan 2002 16:20:31 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Anders Andersson <anders@hack.org> Cc: Jordan Hubbard <jkh@winston.freebsd.org>, Dallas De Atley <deatley@apple.com>, arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <3C588DCF.AFC83B3@mindspring.com> References: <tlambert2@mindspring.com> <3C57BED2.E1144F41@mindspring.com> <66467.1012412972@winston.freebsd.org> <20020130175639.GB2437@sushi.sanyusan.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Anders Andersson wrote: > On Wed, Jan 30, 2002 at 09:49:32AM -0800, Jordan Hubbard wrote: > > Even the NetBSD/amiga port uses gcc. > > NetBSD/amiga just very recently got ANSIfied also :-) I run SVR3.2, the last MMU-less System V, on my 68010 Amiga, not NetBSD, so it's irrelevent whether or not NetBSD/Amiga has been ASNI-fied as to whether or not the FreeBSD source code that I am interested in can be succeffuly compiled with a minimum of effort on platforms other than GCC, or, in the limit, platforms other than *BSD, or platforms other than FreeBSD. This is a code protability and comparative maintenance problem (and, to some, also an aesthetic problem). I consider the __P() to be ugly, but it solves some real problems: 1) Until NetBSD and OpenBSD follow suit, removing __P() will increase cosmetic differences, and therefore will incresingly impede code sharing. 2) The same is true for Darwin/MacOS X and BSD/OS; while it can be argued that BSD/OS is a marginal player at best (though FreeBSD still appears to be in the process of porting code from it), the same argument can not be made of Darwin/MacOS X. 3) I realize that the post that started this thread was by an Apple employee who could not see the use of the __P() construct, and had been referred to this forum by Jordan, and that this argues that the Darwin/MacOS X camp would be happy to go along with removing the __P(), if that were the consensus for the code involved. However, we should note that the MacOS UDF FS implementeation depends on having both block and character devices, so it is already a divergent code base, and we should be mindful of that fact. The bottom line is that the policy is *already* to not put it in to new code, and to use prototypes instead, rendering new code non-portable to older platforms and uncompilable by older tool chains. While I may disagree with this policy strenuously, it is the stated policy of the FreeBSD Project. People will remember that I noted that this was the policy in my very first posting in this thread. With that in mind, we are now talking about the liberal interpretation of that policy when visiting code that is not new, and making that change to code shared with the other *BSD variants, OpenBSD, NetBSD, Darwin/MacOS X, and BSD/OS. This liberal interpretation has been made by some to justify an increase n the cosmetic changes. While I agree that it improves the aesthetics of the code, I also believe that it damages both portability, and the ability to track differences between the code bases. I am also probably not alone in being a BSD person who would be just as happy with the FreeBSD, NetBSD, and OpenBSD code bases moving toward unification, even if such is more than a decade away, and with the Darwin/MacOS X code base being even more literally derived from the FreeBSD code base. I believe that removing the __P() macro -- indeed, removing all of the uses of the cdefs.h header file at all -- must, minimally, be done with the consensus of the NetBSD and OpenBSD and Darwin/MacOS X code bases to do the same. As an intentionally marginalized player, waiting for BSD/OS to agree to follow suit is not necessarily a requirement, but it is, to my mind, desirable to solicit such participation as possible from that camp, should the consensus decision be made by the other *BSD to go in that direction. I fear that yielding to full dependency on a single tool chain is not a good idea for the long term. Putting aside the argument that the next version of the license could be modified to apply to the GCC components that are liked into every program, thus causing a monumental problem going forward (Brett Glass, by advocating this position has thereby painted it as alarmist), there is another problem: the GCC does not generate as good code as the commercial compilers for non-Intel platforms. Indeed, even for Intel platforms, the "how to compile code for the Pentium 4" document reads as a litany of why one should not build their compiler in the way that GCC has built its compiler. While we may now argue that "the Alpha platform is dead", and justify in our own minds thereby the idea that GCC dependence is acceptable for that platform, that does not fix the known problems with GCC code generation for the IA64, Pentium 4, or SPARC processors, which we can not so quickly dismiss. As we have learned -- or should have learned -- diversity in the OS ecosystem is a positive influence on the code: it is better for having a Linux, a UnixWare, a Solaris, and, yes, a Windows NT. Artificially limiting code diversity in the realm of compilers seems, to me, an obvious mistake. It is my wish that, if nothing else be taken from this discussion, that people at least take this: The total removal of __P() or cdefs.h itself is not a decision which can be made in isolation by FreeBSD, with disregard for the other *BSD communities, and without a consensus that all will make the change at around the same time, if the change is in fact inevitable. Even if I personally believe such a decision to be misguided by youth and a zeal to discard inconvenient history, it is at least better that all the code move or none of the code move, than it is that some moves and some does not. Thank you, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C588DCF.AFC83B3>