[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120811023602.GF27715@brightrain.aerifal.cx>
Date: Fri, 10 Aug 2012 22:36:02 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Priorities for next release?
On Fri, Aug 10, 2012 at 10:21:21PM -0400, idunham@...abit.com wrote:
> >>>> - Blowfish crypt
> >>>> - MIPS dynamic linker
> >>>> - Major MIPS bug fixes
> >>>> - ARM hard float support
> all very good...
> Out of curiousity, have you (or anyone else, for that matter) checked how
> much of the LSB ABI is supported as of yet?
No, unfortunately the published LSB is fairly outdated, and glibc
programs built with special options like certain inlining options or
-D_FORTIFY_SOURCE depend on symbols that are not in LSB (as published)
even if they don't use any nonstandard interfaces at the source
level..
> Also, if we're talking about adding MD5 or SHA (of the two, I think sha is
> the more important) along the line, I'd think that adding multiple
> crypt-related APIs in one release makes sense. Not all that important,
> though.
Yes, I tend to agree, both that SHA is more important and that it
would be nice to get them all added in one release.
> I'm guessing that merging ppc/mips64/microblaze ports will end up waiting
> for another release?
Depends on how inspired I get.. ;-)
An experimental merge could definitely happen before a release if I
jump into it. Having something well-tested and promoted as
complete/working is not going to happen.
> >>>> Among the other improvements that are pending, what else would you
> >>>> like to see in 0.9.4?
> >>>
> >>> As annoying as it is XOPEN ifdeffery would be a boon...
> >>
> >> What do you mean?
> >
> > -D_XOPEN_SOURCE=600 and such.
>
> Points to consider:
> 1-it might slow down compiling and make headers ugly.
> 2-as the person who added _BSD_SOURCE, I can assure you that it's not a
> quick project. And with school starting in 2 weeks, I'm not the one doing
> it.
> (I don't think it's going to happen timely enough for the next release,
> certainly)
> 3- -D_GNU_SOURCE will do for building most of this stuff
> 4-if you want a header change, may I politely suggest that you do the
> patches?
I agree with all these points. I think trying to support multiple
versions of the standards adds a lot of complexity with little
tangible benefit.
One variation that might be useful however is adding things like
#if defined(_XOPEN_SOURCE) && _XOPEN_SOURCE <= 600
as a condition around things that were removed in SUSv4 but previously
widely used, like gethostbyname and usleep. Of course the
corresponding tests for _POSIX_C_SOURCE would also belong there, as
appropriate.
Making -D_XOPEN_SOURCE=600 hide the new stuff from SUSv4 would just be
gratuitous ugliness in my mind, but making it re-expose stuff that was
removed later sounds potentially useful.
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.
