Date: Wed, 05 Feb 1997 13:38:43 -0700 From: Warner Losh <imp@village.org> To: obrien@NUXI.com (David O'Brien) Cc: freebsd-ports@freebsd.org (FreeBSD ports list), hackers@freebsd.org Subject: Re: conditionally including <sys/param.h> Message-ID: <E0vsE7A-0001fr-00@rover.village.org> In-Reply-To: Your message of "Wed, 05 Feb 1997 11:19:13 PST." <19970205111913.YS06559@dragon.nuxi.com> References: <19970205111913.YS06559@dragon.nuxi.com> <19970205003343.YB13323@dragon.nuxi.com> <19970202135048.PN07710@dragon.nuxi.com> <199701280143.RAA06503@freefall.freebsd.org> <Pine.OSF.3.95q.970127210526.2115E-100000@uplink.eng.umd.edu> <E0vrw2G-0000I7-00@rover.village.org> <E0vs94u-0000u5-00@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <19970205111913.YS06559@dragon.nuxi.com> David O'Brien writes: : RIGHT. That is *why* I want __44bsd__, to know it is safe to included : <sys/param.h>. I'm not saying __44bsd__ has to be a replacement for the : BSD macro. Although for the easy stuff, why not. Maybe we should be defining the _BSD* macros that posix mandates :-). Or rather suggests. : On a side note, the BSD macro isn't that helpful. I know of few people : that really know if a feature we have has been around since Net/2, or : 4.4Lite. So most people take a wild stab at it. So would __44bsd__ be : any worse? But this is a knowable thing. __44bsd__ would likely be abused for things it has no business controlling. : > It would be better to find a foolproof way of knowing when sys/param.h : > is available (or at least when it generally isn't). : : Right, which is what I am trying to do. But your way is too exclusive. It cuts out too many systems that have sys/param.h that could be used to know things. : Remeber what I'm trying to do here, this is for the ports collection. : I'm trying to solve a problem I come across quite often in making a port. : I don't think I can get an author to accept that big of a change to his : code. With your solution, I would have to worry that some Unix doesn't : have the macro that I want to use from pathnames.h. Yes. I understand that. It is easy enough to #include pathnames.h, and then do #ifndef's. You'll likely have to carry along a seprate pathnames.h for the application that would be tailored to each OS that doesn't define these for you. That's a little larger change to the ports, but still a fairly minor one since it buys extra portibility. : When other Unixes took parts from BSD in the past, they dont' define our : macro. System V to my knowledge (which took many things from BSD), : doesn't define BSD. So there is little to no reason to expect the above : to happen. I believe that SYSVr4 does define the BSD macro. Solaris certainly does since Solaris 2.0 ( well, SunOS has at least since 4.0, and I think since 3.x). : > Many of the ports have 2-3 lines of ifdefs to include stdlib.h, when : > instead they should have a single #ifdef __STDC__ in its place. : : Because, GCC will define __STDC__ because the compiler can handle it. : BUT that doens't mean GCC found stdlib.h when it fixed up the headers. : GCC on SunOS defines __STDC__, but you will find it's native headers : (which GCC uses), aren't. But those headers *ARE* there when __STDC__ is defined. At least on the last SunOS system that I checked gcc adds them. This was in 2.5.8 of gcc, so this has been happening for a long time. That's what __STDC__ means: that I implement the ANSI standard. There are some compilers that do define it to be non-standard values, but they are mostly ancient versions of compilers for the PC, Amiga or Mac. However, as Bruce pointed out, there are other reasons for not doing this. I think that they aren't necessarily valid in the context we're talking about (since we don't compile the ports -traditional), but it may make a difference on some platforms. Just so that we're on the same page, are you suggesting that we do #ifdef _BSD44 #include <sys/param.h> #endif instead? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0vsE7A-0001fr-00>