[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140519224501.GS507@brightrain.aerifal.cx>
Date: Mon, 19 May 2014 18:45:01 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Open issues at end of April
On Thu, May 01, 2014 at 08:17:58AM +0300, Timo Teras wrote:
> 1. I would need to have cp437 and cp850 in iconv. Otherwise mtools
This one is done now.
> 2. Possibly also sysconf() fixes: mapping table 0 to return value -1,
> and fixing LONG_BIT should be done.
I did the -1 stuff, and added a distinction between -1 as "no fixed
limit" and -1 as "invalid argument" (the latter now sets EINVAL).
LONG_BIT etc. could in principle be supported (though ULONG_MAX is
nonsense) but I'd like to hold off on adding something that's rather
silly (not runtime variable) and probably shouldn't be there. Since
it's not (can can't be) runtime variable, getconf(1) should probably
just hard-code these (using limits.h) if it wants to provide them.
> 3. I also think having CFI for at least syscall_cpi should be done.
> Debugging without that is a pain.
As we discussed, let's leave this as a local patch on your side for
now. I'm still hoping (perhaps this is futile :/) to find a way to do
it that (1) doesn't uglify all the sources, and (2) automatically gets
omitted from .o files when debug symbols are turned off (since .o
files compiled from C source won't have it, it doesn't make sense for
the ones from asm source to have it).
> 4. Other items in my wish list is "sendmmsg() and recvmmsg()" but as
> discussed it's tricky.
Yes, even some new issues came up: emulating with sendmsg/recvmsg is
not valid because the timeout can't be emulated. However I think we
could emulate sendmmsg with N messages as N calls to sendmmsg with
just one message each, or some similar breakdown, such that the amount
of data that needs to be copied and patched-up is bounded.
> 5. And I also had the question if for NEEDED dependencies constructors
> should be topologically sorted.
I'd like to avoid making any guarantees about ctor/dtor order; doing
so can place nasty constraints on how some dynamic-loading situations
are handled, and only benefits broken apps/libs. I think you can get
similar behavior in a clean portable way by having init functions that
run as ctors also call (via pthread_once) the other init functions
they depend on.
Rich
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.
