Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Sep 2012 00:17:34 -0400 (EDT)
Subject: Re: R/GNU S: up with a couple hitches...

> On Fri, 14 Sep 2012 23:51:10 -0400
> Rich Felker <> wrote:
>> On Fri, Sep 14, 2012 at 08:21:07PM -0700, Isaac Dunham wrote:
>> > Not yet, unless you're using the g_hack branch and don't need rpc to
>> > actually _work_. libtirpc needs getifaddrs.
>> Is the getifaddrs code there license-compatible with musl?
> Yes but it's only a stub I wrote (hence the comment about "don't need rpc
> to actually _work_"). It will almost certainly leave any software that
> uses getifaddrs crippled.
> And no, I' haven't tested what builds with it. Probably nothing in its
> present state (I don't have a proper header yet).

I have since gone looking and found that newlib has a BSDi-based version,
which looks like it might be usable on some arches with some minor (?)
changes and cleanup.  There's a note about one codepath not being LP64
friendly, though, as well as one abort() that should be turned into a
retry or failure. (Apple used the same base for implementing getifaddrs,
Refer to newlib/libc/sys/linux/net/getifaddrs.c in the newlib source tree.
Not sure if
(elinks) src/osdep/getifaddrs.c
are worthwhile, though they are compatibly licensed (BSDi or 3-clause

> Also, I have mentioned once or twice that getifaddrs, when implemented,
> will require (BSD) <sys/queue.h> TAILQ_* macros. If any header contains
> copyrightable material, it's this one: hundreds of LOCs, implementing
> linked lists in macros.
<sys/queue.h> will only be needed for source compatibility only, not for
implementing it.

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.