|
Message-ID: <20120406001049.GA8803@brightrain.aerifal.cx> Date: Thu, 5 Apr 2012 20:10:49 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Namespace issues, missing functions, _BSD_SOURCE for unistd.h On Thu, Apr 05, 2012 at 03:55:08PM -0700, Isaac Dunham wrote: > Attached is a patch that should add proper BSD_SOURCE support for > <unistd.h>. I'm not sure that the formatting/style is proper, and the > exact arrangement is rather arbitrary. But I've moved a lot of things > that were wrongly grouped in either ANSI namespace or GNU-only > namespace. There is no "ANSI" namespace in unistd.h because it's not a standard C header but a POSIX header. It's definitely correct for POSIX 2008 base as-is without any patching. > BSD || XOPEN means the macro test should be > #if defined(_BSD_SOURCE) || defined(_XOPEN_SOURCE) > I see glibc turns on both of these with _GNU_SOURCE. Yes, I think you overlooked some of the logic of how glibc's features.h works... > Misplaced (should be BSD || XOPEN): > (Properly, these require XOPEN >= 500) > usleep, ualarm, fchown, fchdir, lchown,vhangup, > apparently fsync? All incorrect. usleep and ualarm were removed by SUSv4/POSIX 2008 and thus do not belong in any profile except ones with nonstandard extensions. fchown, fchdir, and lchown are all POSIX 2008 base. vhangup was perhaps standard at one time but removed; it's only in the nonstandard profiles now. > Missing (BSD || XOPEN): > getwd,ttyslot,sethostid,get/setdomainname,revoke,profil,acct,get/end/setusershell AFAIK most of these do not exist in musl at the moment. > BSD||GNU: > setlogin, getpass > > These and chroot also should be available with lower values of > _XOPEN_SOURCE > > Incompatible: > BSD uses setpgrp the same way everyone else uses setpgid--a > substitution macro will do the job. That's what glibc does and what I > did. So far musl's policy with GNU brokenness has been not to duplicate any brokenness that conflicts with the standard behavior of standard functions and makes them nonconformant. I intend to take the same approach with BSD. _BSD_SOURCE should simply mean "make BSD extensions available", not "break standard functions to duplicate broken legacy BSD behavior". > +#if defined(_BSD_SOURCE) && !defined(L_SET) > +#define L_SET > +#define L_INCR > +#define L_XTND > +#endif I don't see how blank definitions can be useful for these... > +#if defined(_BSD_SOURCE) && !defined(_POSIX_C_SOURCE) \ > + && !defined(_POSIX_SOURCE) && !defined(_XOPEN_SOURCE) \ > + && !defined(_GNU_SOURCE) > +#define setpgrp setpgid > +int symlink(const char *, const char *); > +#endif Moving symlink here is definitely wrong. And see above about setpgrp. > +#if !( (_POSIX_SOURCE - 0) < 200112L ) > +int seteuid(uid_t); > +int setegid(gid_t); > +#endif I have no intention of trying to make a profile that conforms to the 1990 version of POSIX. > +#if defined(_BSD_SOURCE) || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) > +int setreuid(uid_t, uid_t); > +int setregid(gid_t, gid_t); Definitely wrong. These are POSIX base. > +int fchown(int, uid_t, gid_t); > +int lchown(const char *, uid_t, gid_t); > + > +int fchdir(int); And so are these. > +pid_t vfork(void); > +int vhangup(void); > +int usleep(unsigned); > +unsigned ualarm(unsigned, unsigned); And these do not exist in SUSv4. (The first two are not in SUSv3 either.) Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.