> "Richard L. Hamilton" <[EMAIL PROTECTED]> wrote: > > > that is, tracking those that it has that > [Open]Solaris currently doesn't, > > and at least for those whose description appears to > be unlikely to change, > > implementing them, such that they're available ASAP > once the final > > revision to the spec comes out (this year, I > think!)? If there were such a list, > > I'd like to think it wouldn't be too bad to get > people to sign up to write them. > > I believe we had a similar discussion before, at that > time it turned out that > we have a different idea from "are unlikely to > change" than Some people from > Sun.
Given the behavior of committees, if the people from Sun have more experience with them, maybe they're right. OTOH, I think one could still sometimes be more sure than others, esp. if there's enough precedent the committee might not want to confront of if the function is simple enough. Other times, one might err in terms of something more restrictive that could always be made compatibly less restrictive later (like using const and restrict modifiers when they might make sense; taking them away later might not require a distinct version, but adding them later probably would). I've signed up for access to get the latest Austin Group draft, and I think I'll try to make a list of what's missing and maybe code some of the simpler ones. Even if one were worried, couldn't they just go into something other than libc, and identified as volatile? That way, they'd be there for porting, but any changed standardized versions could just be added to libc when they came out. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
