This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Standards References
Rical-
Sorry on being late to this thread, but I do have access to some of this
old stuff (having worked on POSIX etc for the last 20 years :-/ )
Contact me offline at the email address below, with your wish list, and
I'll see what I can do. I am slightly constrained by copyright issues
but at the same time since this is "for standardization purposes" I will
probably be able to help you anyway :-)
On 10/14/2016 11:33 AM, Rical Jasan wrote:
> On 10/13/2016 11:32 PM, Carlos O'Donell wrote:
>> On 10/14/2016 01:22 AM, Rical Jasan wrote:
>>> Point being, that list is by no means complete, but should work for the
>>> following question:
>>>
>>> * Where can I find the references for these standards?
>>
>> That is a fairly broad and difficult to answer question.
>
>> Many of the older standards are very difficult to get today.
>
>> The Open Group has the largest collection that I am aware of and several
>> of them are free to access (you may need an account):
>> http://www.opengroup.org/standards/unix
>> http://pubs.opengroup.org/onlinepubs/007908799/
>> http://www.unix.org/version2/
>
> So far I've been going to pubs.opengroup.org primarily (no account), so
> I'm glad I was on the right track.
Yes, these are the correct starting points.
>> The ISO standards are accessible also directly from WG14:
>> http://www.open-std.org/jtc1/sc22/wg14/www/standards
>>
>> The three most important standards for glibc are:
>> * POSIX Issue 7:
>> http://pubs.opengroup.org/onlinepubs/9699919799/
>> * ISO C11 (N1570)
>> * IEEE 754-2008 (only for sale from the IEEE)
>> https://standards.ieee.org/findstds/standard/754-2008.html
>
> Thank you; good to know.
I may have access to some of these, contact me privately :-)
>> One thing to note is that there is a difference between 'the name of
>> the function comes from standard X' and 'the function implements what
>> standard X says it does', and these two don't always match. Like the
>> POSIX scheduling functions do not do what POSIX says they do, instead
>> they match more closely what Linux does. So it's not entirely clear
>> if those functions are buggy, should get fixed to comply, or should
>> not be defined if you're goal is to use only functions from a given
>> standard.
>
> Interesting. Is there precedence within the feature test macros, where
> the Linux standard supersedes POSIX, or vice versa, or is it possible to
> dictate that behaviour? This seems orthogonal, like a question that
> should be answered in the implementation/headers, ultimately. If that
> conflict already exists in practice, do you consider it buggy, broken,
> or worth omitting? I imagine we could devise a syntax for such cases,
> though.
I can walk you through the usual precedence...I am traveling right now
but willing to help.
>
> When I do cull my knowledge from the sources, I don't copy/paste
> anything. If I can't restate it in a meaningful way from my own
> understanding, I don't think I should writing the documentation for it
> anyway. But thank you for making that explicit, as I wouldn't have been
> aware otherwise.
>
> Should I avoid reading man pages for functions that aren't documented in
> the glibc manual but that I intend on documenting because they are
> present in the source, but absent from the manual?
This is a bit of a minefield, with some well-known exceptions made for
documention but only in some cases...let's talk.
I can also hook us up with the coordinator for the Single UNIX
Spec/POSIX effort if need be.
--
Mark Brown
ms_brown@sbcglobal.net