Date: Thu, 10 Oct 2002 10:55:31 -0400 From: Craig Rodrigues <rodrigc@attbi.com> To: freebsd-standards@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <20021010105531.A12354@attbi.com> In-Reply-To: <20021010205529.M8598-100000@gamplex.bde.org>; from bde@zeta.org.au on Thu, Oct 10, 2002 at 09:31:56PM %2B1000 References: <20021009232056.A10429@attbi.com> <20021010205529.M8598-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote: > Perhaps because they wanted you to use sysconf() instead of these mistakes. Well in the case of ACE, it is a C++ library that is compiled on platforms which may or may not have sysconf() (ie. Windows), so using sysconf() is not practical in this case. Checking a feature macro is much easier. > > This is variant of the above verbose version. It requires slightly more > modern compilers, so it might fail for some 20-year old pre-Standard C > compilers instead of only for some 25-year old ones. ACE makes some pretty aggressive use of C++ features, so luckily compliance with 20-25 year old compilers is not a requirement. :) Support for gcc 2.7.2 and 2.8 compilers was dropped recently. It will be really exciting to use ACE on FreeBSD 5.x since gcc 3.2.1 has some fairly good support for modern C++ features. > I used a variant your patch for this in PR 35924 until recently when Wow, I forgot that I filed 35924! :) Thanks for reminding me. > I noticed that it usually worked for the bogus reason that <unistd.h> > is not included, then _POSIX_REALTIME_SIGNALS is only defined accidentally > (to whatever value). I now use just #if 0 and an XXX comment as a > reminder to fix this someday: > > %%% > Index: signal.h > =================================================================== > RCS file: /home/ncvs/src/include/signal.h,v > retrieving revision 1.19 > diff -u -2 -r1.19 signal.h > --- signal.h 6 Oct 2002 21:54:08 -0000 1.19 > +++ signal.h 7 Oct 2002 07:06:19 -0000 > @@ -78,9 +79,18 @@ > > #if __BSD_VISIBLE || __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 600 > +#if 0 > +/* > + * PR: 35924 > + * XXX we don't actually have these. We set _POSIX_REALTIME_SIGNALS to > + * -1 to show that we don't have them, but this symbol is not necessarily > + * in scope (in the current implementation), so we can't use it here. > + */ > int sigqueue(__pid_t, int, const union sigval); > +struct timespec; > int sigtimedwait(const sigset_t * __restrict, siginfo_t * __restrict, > const struct timespec * __restrict); > int sigwaitinfo(const sigset_t * __restrict, siginfo_t * __restrict); > #endif > +#endif > > #if __BSD_VISIBLE || __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE > %%% > > The patch also moves the forward declaration of struct timespec near to > the one place that it is used (related patches not included). This > mainly makes it obvious that the messy visibility for it is the same > as the one for the function that uses it. This patch works for me. I think it is just as easy to just remove cruft from the header file entirely, but since your patch effectively does the same thing and has informative comments, that is fine. If your patch (or some equivalent variant) is committed, then I think PR 35924 can be closed. Something needs to be done about these prototypes. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021010105531.A12354>