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.