Re: addition to cdefs
On Wed, 13 Nov 2002, Mike Barcroft wrote:
Bruce Evans [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: addition to cdefs
On Tue, 12 Nov 2002, Archie Cobbs wrote:
Marc Recht [EMAIL PROTECTED] writes:
I've had the attached patch in my tree for a while. I'll try and get
it and the unistd.h patch committed today.
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
n = _howmany(n, _NFDBITS);
while (n 0)
p-fds_bits[n--] = 0;
}
That looks broken. Maybe you meant this:
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
n = _howmany(n, _NFDBITS);
while (n 0)
p-fds_bits[--n] = 0;
}
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).
But why not just this?
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
memset(p-fds_bits, 0, _howmany(n, _NFDBITS));
}
As already pointed out in another reply, memset() gives the same namespace
problems as this function exists to avoid. __builtin_memset() could be
used if the compiler is gcc.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: addition to cdefs
Bruce Evans [EMAIL PROTECTED] 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?
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: addition to cdefs
On 11 Nov 2002 17:56:08 +0100, Marc Recht [EMAIL PROTECTED] said: I'm thinking more of it like an aggregation. IMHO it should be possible, if the user wants to, to get POSIX 199506 and BSD. That would be very difficult, since FreeBSD never supported that version (indeed, never even claimed support for that version). In order to make this happen, someone would have to go back to a printed copy of ISO/IEC 9945-1:1996 and compare all of the text against what is in FreeBSD to determine the appropriate conditionals. (That's not counting any semantic changes.) I've already done some of this work, and it's a lot of hard work (not least because of the way the previous POSIX standards were structured) for very little gain (since FreeBSD/i386 has never correctly supported any version of POSIX, not even the one it used to claim to support). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: addition to cdefs
Marc Recht [EMAIL PROTECTED] writes:
I've had the attached patch in my tree for a while. I'll try and get
it and the unistd.h patch committed today.
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
n = _howmany(n, _NFDBITS);
while (n 0)
p-fds_bits[n--] = 0;
}
That looks broken. Maybe you meant this:
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
n = _howmany(n, _NFDBITS);
while (n 0)
p-fds_bits[--n] = 0;
}
But why not just this?
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
memset(p-fds_bits, 0, _howmany(n, _NFDBITS));
}
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: addition to cdefs
On Mon, 11 Nov 2002 09:54:58 -0500, Mike Barcroft [EMAIL PROTECTED] said: /* 1003.2-1992 */ -#if __POSIX_VISIBLE = 199209 +#if __POSIX_VISIBLE = 199209 || __XSI_VISIBLE size_tconfstr(int, char *, size_t); int getopt(int, char * const [], const char *); __XSI_VISIBLE should never be non-zero when __POSIX_VISIBLE is less than 199506, so I don't entirely understand what's going on here. We don't really support XPG4.2 or older environments. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: addition to cdefs
On Tue, 12 Nov 2002 15:49:05 -0800 (PST), Archie Cobbs [EMAIL PROTECTED] said:
But why not just this?
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
memset(p-fds_bits, 0, _howmany(n, _NFDBITS));
}
Because a declaration of memset() is not permitted in that context.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: addition to cdefs
Marc Recht [EMAIL PROTECTED] writes: Hi! I've made a small patch to make it possible to enable BSD extensions although _POSIX_SOURCE, _POSIX_C_SOURCE or _XOPEN_SOURCE has been defined. This is made with a new define _BSD_SOURCE right after the XOPEN_SOURCE handling. It sets __XSI_VISIBLE 600 and __BSD_VISIBLE 1. This is needed for some programs. For example for Python 2.3cvs sets (among others) _POSIX_C_SOURCE 199506L, but also expects to have chroot and friends. It looks like unistd.h has some XSI bugs. Is _XOPEN_SOURCE defined anywhere? If so, try the attached patch. If not, this is a bug in Python (since POSIX doesn't specify chroot()) and should be fixed at their end and in the ports collection. _BSD_SOURCE provides mostly the same visibility as not defining any standards constants, so it isn't very useful. Best regards, Mike Barcroft Index: unistd.h === RCS file: /work/repo/src/include/unistd.h,v retrieving revision 1.63 diff -u -r1.63 unistd.h --- unistd.h28 Oct 2002 00:15:43 - 1.63 +++ unistd.h11 Nov 2002 14:48:50 - @@ -361,7 +361,7 @@ ssize_t write(int, const void *, size_t); /* 1003.2-1992 */ -#if __POSIX_VISIBLE = 199209 +#if __POSIX_VISIBLE = 199209 || __XSI_VISIBLE size_t confstr(int, char *, size_t); int getopt(int, char * const [], const char *); @@ -370,7 +370,7 @@ #endif /* ISO/IEC 9945-1: 1996 */ -#if __POSIX_VISIBLE = 199506 +#if __POSIX_VISIBLE = 199506 || __XSI_VISIBLE int fsync(int); /* @@ -381,13 +381,18 @@ #define_FTRUNCATE_DECLARED int ftruncate(int, off_t); #endif +#endif +#if __POSIX_VISIBLE = 199506 int getlogin_r(char *, int); #endif /* 1003.1-2001 */ -#if __POSIX_VISIBLE = 200112 +#if __POSIX_VISIBLE = 200112 || __XSI_VISIBLE int fchown(int, uid_t, gid_t); +int readlink(const char *, char *, int); +#endif +#if __POSIX_VISIBLE = 200112 int gethostname(char *, int /* socklen_t */); int setegid(gid_t); int seteuid(uid_t); @@ -408,6 +413,7 @@ /* char*ctermid(char *); *//* XXX ??? */ int encrypt(char *, int); int fchdir(int); +longgethostid(void); int getpgid(pid_t _pid); int getsid(pid_t _pid); char *getwd(char *); /* LEGACY: obsoleted by getcwd() */ @@ -432,13 +438,20 @@ #endif #endif /* __XSI_VISIBLE */ +#if __XSI_VISIBLE = 500 || __BSD_VISIBLE +int brk(const void *); +int chroot(const char *); +int getdtablesize(void); +int getpagesize(void) __pure2; +char *getpass(const char *); +void *sbrk(intptr_t); +#endif + #if __BSD_VISIBLE struct timeval;/* select(2) */ int acct(const char *); int async_daemon(void); -int brk(const void *); int check_utility_compat(const char *); -int chroot(const char *); const char * crypt_get_format(void); int crypt_set_format(const char *); @@ -448,12 +461,8 @@ int exect(const char *, char * const *, char * const *); char *fflagstostr(u_long); int getdomainname(char *, int); -int getdtablesize(void); int getgrouplist(const char *, gid_t, gid_t *, int *); -longgethostid(void); mode_t getmode(const void *, mode_t); -int getpagesize(void) __pure2; -char *getpass(const char *); int getpeereid(int, uid_t *, gid_t *); int getresgid(gid_t *, gid_t *, gid_t *); int getresuid(uid_t *, uid_t *, uid_t *); @@ -483,7 +492,6 @@ const char *, const char *, const char *); char *re_comp(const char *); int re_exec(const char *); -int readlink(const char *, char *, int); int reboot(int); int revoke(const char *); pid_t rfork(int); @@ -491,7 +499,6 @@ int rresvport(int *); int rresvport_af(int *, int); int ruserok(const char *, int, const char *, const char *); -void *sbrk(intptr_t); #if __BSD_VISIBLE #ifndef _SELECT_DECLARED #define_SELECT_DECLARED
Re: addition to cdefs
Thanks! It looks like unistd.h has some XSI bugs. Is _XOPEN_SOURCE defined anywhere? If so, try the attached patch. If not, this is a bug in Yes, _XOPEN_SOURCE is defined. So, it solves some of the problems. Python (since POSIX doesn't specify chroot()) and should be fixed at their end and in the ports collection. But, there still some problems left. Like fd_set being not defined in sys/select if _BSD_VISIBLE isn't given. _BSD_SOURCE provides mostly the same visibility as not defining any standards constants, so it isn't very useful. IMO it would be nice to have a clean way to toggle __BSD_VISIBLE from the outside. In the default environment I have #define __POSIX_VISIBLE 200112 #define __XSI_VISIBLE 600 #define __BSD_VISIBLE 1 #define __ISO_C_VISIBLE 1999 But, Python for example, wants _POSIX_C_SOURCE 199506,_XOPEN_SOURCE 500 _and_ __BSD_VISIBLE 1. I know, I could also just do a -D__BSD_VISIBLE=1, but I think thats not The Right Thing to do. Regards, Marc -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: addition to cdefs
I've had the attached patch in my tree for a while. I'll try and get it and the unistd.h patch committed today. Thanks! This solves some problems, but there are some left. Mostly socket and rpc related. For example PF_INET and friends are undefined.. The whole point of the standards constants is to specify a strict environment. If you want a BSD environment don't specify a particular standard, it's simple. I'm thinking more of it like an aggregation. IMHO it should be possible, if the user wants to, to get POSIX 199506 and BSD. Regards, Marc -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: addition to cdefs
Marc Recht [EMAIL PROTECTED] writes: I've had the attached patch in my tree for a while. I'll try and get it and the unistd.h patch committed today. Thanks! This solves some problems, but there are some left. Mostly socket and rpc related. For example PF_INET and friends are undefined.. This one looks like a problem on Python's end. sys/socket.h is new in POSIX.1-2001, so including it in a strictly conforming older POSIX or X/Open program is wrong. I could recommend either specifying 200112 for the POSIX version (likewise the X/Open) constant or not specifying a standard. The whole point of the standards constants is to specify a strict environment. If you want a BSD environment don't specify a particular standard, it's simple. I'm thinking more of it like an aggregation. IMHO it should be possible, if the user wants to, to get POSIX 199506 and BSD. With no standard environment specified, all POSIX.1-1996 objects should still be available. Can you provide an example where no constants specified would differ from _BSD_SOURCE and _POSIX_C_SOURCE being specified? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
