Re: Agenda for next release?

[Brad Conroy <technosaurus@yahoo.com>]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

Not functionally necessary for the release, but nice for future compatibility reasons, a few paths are hard-coded into the c files rather than defining them in the (non-)"standard" location
Ex.src/network/getaddrinfo.c has "/etc/hosts", "/etc/resolve.conf" and "/etc/services" hard-coded rather than defining them in netdb.h
#define _PATH_HOSTS "/etc/hosts"#define _PATH_NSSWITCH_CONF "/etc/nsswitch.conf"#define _PATH_SERVICES "/etc/services"
also defined in netdb.h for other uses

#define _PATH_HEQUIV "/etc/hosts.equiv"#define _PATH_NETWORKS "/etc/networks"#define _PATH_PROTOCOLS "/etc/protocols"

resolv.h does have #define _PATH_RESCONF "/etc/resolve.conf" however src/network/__dns.c still has the hard-coded path also
I'm sure there are others that grep could find (fstab.h,paths.h,ttyent.h xtables.h,???)
also android has etc in /system, so the actual path is /system/etc/hosts (though /etc is typically a symlink to /system/etc), but other strange layouts exist and it would be a lot easier/cleaner for work arounds to have the ifdefs confined to one location in the header files and use those definitions in the .c files so that port patches only hit a few headers without polluting the .c files with a lot of ifdef nests
I ran into this while building a static wget-like downloader that would use an alternate hosts file to complement a custom local server that locally hosts some problematic CDNs (to work around problems such as: waiting for ajax.googleapis.com, platform.twitter.com etc...) but this is an obvious hack, not the typical use case for a standard library... but then again part of the charm of musl is its "hackability"

--- On Mon, 12/31/12, Rich Felker <dalias@aerifal.cx> wrote:

From: Rich Felker <dalias@aerifal.cx>
Subject: [musl] Agenda for next release?
To: musl@lists.openwall.com
Date: Monday, December 31, 2012, 2:11 PM

Hi,

I don't have any immediate plan for the next release, but I'd like to
start thinking about what we'd like to go into it. A few things I know
are still pending that should be possible to include are:

- strverscmp
- zoneinfo
- inet_makeaddr
- scanf %m modifier
- getifaddrs
- cpuset/affinity interfaces
- ether.h interfaces

I know there's also interest in exposing sigreturn and setcontext for
libunwind use, but it's difficult to do right and I'm really skeptical
of the whole thing. Their use of sigreturn seems completely incorrect
(and thus probably untested); sigreturn expects a struct sigcontext on
the stack, not a pointer to a sigcontext in the first function
argument slot. I would rather have a conversation with their
developers first to determine if that code is even working/valid, and
defer the corresponding additions to musl until we eventually add all
the ucontext.h interfaces in working form.

Another port (perhaps x32, like originally proposed) is also
definitely an option if anybody's up for doing it. I had considered
doing it myself in this release cycle, but I'm a bit busy with some
other projects for at least a couple weeks so I'd rather not get
bogged down in a big time-eater right away, and instead spend my time
with musl on small isolated feature additions and bug fixes.

Anything else I missed?

Rich

[-- Attachment #2: Type: text/html, Size: 5532 bytes --]