mailing list of musl libc
 help / color / mirror / code / Atom feed
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.





      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).