[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
