mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Namespace issues, missing functions, _BSD_SOURCE for unistd.h
Date: Thu, 5 Apr 2012 20:10:49 -0400	[thread overview]
Message-ID: <20120406001049.GA8803@brightrain.aerifal.cx> (raw)
In-Reply-To: <20120405155508.0f782675@newbook>

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


  reply	other threads:[~2012-04-06  0:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05 22:55 Isaac Dunham
2012-04-06  0:10 ` Rich Felker [this message]
2012-04-06  1:03   ` Isaac Dunham
2012-04-06  1:52     ` Rich Felker
2012-04-06  1:45   ` [PATCH] _BSD_SOURCE for unistd.h, take 2 Isaac Dunham
2012-04-06  2:04     ` Rich Felker
2012-04-06  2:40       ` Isaac Dunham
2012-04-06  2:51         ` Rich Felker
2012-04-06 14:48     ` Rich Felker
2012-04-06 15:48       ` Isaac Dunham
2012-04-06 23:32         ` Rich Felker
2012-04-07  5:47           ` Isaac Dunham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120406001049.GA8803@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).