Date: Fri, 15 Nov 2002 21:57:58 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mike Barcroft <mike@FreeBSD.org> Cc: Archie Cobbs <archie@dellroad.org>, Marc Recht <marc@informatik.uni-bremen.de>, Garrett Wollman <wollman@lcs.mit.edu>, <current@FreeBSD.org> Subject: Re: addition to cdefs Message-ID: <20021115214346.U13981-100000@gamplex.bde.org> In-Reply-To: <20021113103111.B98651@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Nov 2002, Mike Barcroft wrote:
> Bruce Evans <bde@zeta.org.au> writes:
> > Both have large namespace pollution (p and n are in the application
> > namespace). Both give huge code wih a copy of the function in every
> > object file whose source file(s) include this header if inline functions
> > are not actually inline (which happens if the compiler is gcc -O0 or
> > non-gcc).
>
> I fixed the namespace problems in the version I posted for review on
> -standards. Do you see any problems with changing FD_ZERO() to:
>
> #define FD_ZERO(p) do { \
> fd_set *_p = (p); \
> __size_t _n = _howmany(FD_SETSIZE, _NFDBITS); \
> while (_n > 0) \
> _p->__fds_bits[--_n] = 0; \
> } while (0);
>
> ...to overcome the issues with the inline version?
I think avoiding the inline function is especially worthwile here,
since FD_ZERO is is always defined in <sys/types.h> in the default
(__BSD_VISIBLE) case and that won't change soon.
The above version has a bug: the semicolon at the end defeats the point
of the `do ... while (0)'.
I would format it a little differently (tab instead of space after
#define; space instead of tab before `do', and maybe not initialize
variables in declarations, and maybe leave a blank line after the
declarations -- I like to use normal formatting for macros unless
breaking the normal formatting can be used to get 1-line macros.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021115214346.U13981-100000>