On Thu, 3 Dec 2009, Petr Salinger wrote:
We try to support SUSv3, but not all optional parts,
the streams related errors are marked as "OB XSR" by POSIX 2008.
Note that POSIX 2008 is SUSv4, not SUSv3. In my understanding,
XPG4v2 - Issue 4, Version 2 - SUSv1 - UNIX 95
XPG5(?) - Issue 5 - SUSv2 - UNIX 98
Issue 6 - SUSv3 - UNIX 03 - POSIX 2004
Issue 7 - SUSv4 - ? - POSIX 2008
http://www.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
[OB] Obsolescent
The functionality described may be removed in a future version of this volume
of POSIX.1-2008. Strictly Conforming POSIX Applications and Strictly
Conforming XSI Applications shall not use obsolescent features.
[XSR] XSI STREAMS
The functionality described is optional. The functionality described is also
an extension to the ISO C standard.
You're absolutely right, and I was delighted when I read this:
http://www.opengroup.org/press/01jun04.htm
However, with lbzip2, I focus on SUSv2. I define the _XOPEN_SOURCE feature
test macro with value 500 (-> Issue 5), not 600 (-> Issue 6). It is an old
standard, superseded by SUSv3 and SUSv4, and I accept that it is more
reasonable to focus your efforts on new standards. OTOH, I'd like to be
able to compile upstream lbzip2 on the widest range of systems that
support standardized threads, for example
http://lacos.hu/lbzip2-scaling/scaling.html
and that means SUSv2.
Thus you factually (and understandably) do not intend to support SUSv2, at
least not proactively, and that's why I'm a bit in hack-land on
GNU/kFreeBSD. Not only because of stuff that became optional on SUSv3, but
also because of new reserved identifiers. Suppose I want to define a macro
for myself. I check SUSv2:
http://www.opengroup.org/onlinepubs/007908775/xsh/compilation.html
and see that I'm in no conflict. Since I want to support GNU/kFreeBSD if
it doesn't harm portability, now I'll have to check the corresponding
tables in SUSv3 and SUSv4 too, because I cannot ask the implementation
*not* to define anything that's not reserved in SUSv2.
Such things worried people even then, an example from between SUSv2 and
SUSv3:
http://opengroup.org/austin/mailarchives/ag/msg03131.html
The discrepancy was fortunately minimal in this case, and I was able to
amend my code without harming portability to systems I don't know about.
I'm not suggesting you should add these error numbers too, because then
you'll certainly run into code which checks for eg. ENODATA to decide
whether the XSR feature group is present (instead of _XOPEN_STREAMS in
unistd.h).
I have no problem adapting my code to slightly non-SUSv2-conformant
systems if I'm able to compile my code regularly and easily on such
systems, and if the resulting change doesn't harm portability on other
platforms (eg. by non-standard platform test macros).
Sorry for this long rant. Please do correct any mistakes in it.
Thanks,
lacos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
