From: Isaac Dunham <idunham@lavabit.com>
To: musl@lists.openwall.com
Subject: Re: [PATCH] string.h, _BSD_SOURCE, and *index()
Date: Thu, 12 Apr 2012 21:31:28 -0700 [thread overview]
Message-ID: <20120412213128.16183283@newbook> (raw)
In-Reply-To: <20120413033013.GH7281@brightrain.aerifal.cx>
On Thu, 12 Apr 2012 23:30:13 -0400
Rich Felker <dalias@aerifal.cx> wrote:
> On Thu, Apr 12, 2012 at 06:45:22PM -0700, Isaac Dunham wrote:
> > I was working on _BSD_SOURCE for string.h.
> > Warning: several of the functions are mislabeled as _GNU_SOURCE in
> > the manpages.
> > Everything in strings.h should be available if _GNU_SOURCE ||
> > BSD_SOURCE is defined and string.h is included.
>
> #if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> #include <strings.h>
> #endif
>
> Actually I thought that was already there (minus the BSD) but it seems
> I was mistaken. In any case, I think it's cleaner than duplicating all
> the prototypes in 2 places.
Definitely cleaner...
but there are a few repeat definitions. (Some of it is now
_POSIX_SOURCE). But that probably won't break things.
And it could slow down compiles, etc.
>
> > (r)index was X/Open legacy, and has been dropped. The Open Group
> > recommended using
> > #define index(a,b) strchr((a),(b))
> > #define rindex(a,b) strrchr((a),(b))
> > Which will let us remove two more files if we do it (rindex.c &
> > index.c) However, would removing those break the ABI?
>
> Yes. It would also break the API for programs which declare these
> functions manually rather than using the header (that's more popular
> than you think), and as your patch is written it's violating the
> SUSv4 namespace (since these symbols were removed, you can't define
> them).
Huh?
|+#if defined(_BSD_SOURCE) || defined(_GNU_SOURCE)
|+int bcmp (const void *, const void *, size_t);
|+void bcopy (const void *, void *, size_t);
|+void bzero (void *, size_t);
|+int strcasecmp (const char *, const char *);
|+int strncasecmp (const char *, const char *, size_t);
|+char *index (const char *, int);
|+char *rindex (const char *, int);
|+int ffs (int);
|+#endif
I didn't move them in the second patch, either.
>The advice on using macros is advice for _applications_, not
> for implementations.
OK. That answers the question. I wasn't sure, so I did two patches.
prev parent reply other threads:[~2012-04-13 4:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-13 1:45 Isaac Dunham
2012-04-13 1:52 ` Andre Renaud
2012-04-13 3:31 ` Rich Felker
2012-04-13 3:30 ` Rich Felker
2012-04-13 4:31 ` Isaac Dunham [this message]
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=20120412213128.16183283@newbook \
--to=idunham@lavabit.com \
--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).