Re: Standards References

[Mark Brown <ms_brown at sbcglobal dot net>]

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