Re: Priorities for next release?

[Rich Felker <dalias@aerifal.cx>]

On Fri, Aug 10, 2012 at 10:21:21PM -0400, idunham@lavabit.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