Unix Programming - option check and POSIX/SUS standards

Author

option check and POSIX/SUS standards

dodo

2006-09-15, 4:01 am

hi,guys!
i'm now reading both Marc Rochkind 's Advanced Unix Programming and
Richard Stevens and Rago's AUPE 2nd Edtion,and the 'option' part of
POSIX/SUS standards really mess me up.
As descibed by Rago in AUPE 2.6,i think option check has to handle 4
situations no matter which platform it is:undefined ,-1,0,and a value
greated than 0.Use sysconf,pathconf or fpathconf when the option is
undefined or 0,and -1 means unsupported,values above 0 means supporting
it.
but in Marc's AUP 1.5.4 ,the provided function option_async_io havn't
considered the "undefined" situation,and the "0" situation (see line no
00057)is considered as unsupported which is in violation with what Rago
said in AUPE 2.6. The function is as following:
00055 OPT_RETURN option_async_io(const char *path)
00056 {
00057 #if _POSIX_ASYNCHRONOUS_IO <= 0
00058 return OPT_NO;
00059 #elif _XOPEN_VERSION >= 500 && !defined(LINUX)
00060 #if !defined(_POSIX_ASYNC_IO)
00061 errno = 0;
00062 if (pathconf(path, _PC_ASYNC_IO) == -1)
00063 if (errno == 0)
00064 return OPT_NO;
00065 else
00066 EC_FAIL
00067 else
00068 return OPT_YES;
00069
00070 EC_CLEANUP_BGN
00071 return OPT_ERROR;
00072 EC_CLEANUP_END
00073 #elif _POSIX_ASYNC_IO == -1
00074 return OPT_NO;
00075 #else
00076 return OPT_YES;
00077 #endif /* _POSIX_ASYNC_IO */
00078 #elif _POSIX_VERSION >= 199309L
00079 return OPT_YES;
00080 #else
00081 errno = EINVAL;
00082 return OPT_ERROR;
00083 #endif /* _POSIX_ASYNCHRONOUS_IO */
00084 }
00085 /*[]*/
anyway ,what's the matter?

Geoff Clare

2006-09-18, 7:59 am

"dodo" <5515159@gmail.com> wrote, on Fri, 15 Sep 2006:

> hi,guys!
> i'm now reading both Marc Rochkind 's Advanced Unix Programming and
> Richard Stevens and Rago's AUPE 2nd Edtion,and the 'option' part of
> POSIX/SUS standards really mess me up.
> As descibed by Rago in AUPE 2.6,i think option check has to handle 4
> situations no matter which platform it is:undefined ,-1,0,and a value
> greated than 0.Use sysconf,pathconf or fpathconf when the option is
> undefined or 0,and -1 means unsupported,values above 0 means supporting
> it.
> but in Marc's AUP 1.5.4 ,the provided function option_async_io havn't
> considered the "undefined" situation,and the "0" situation (see line no
> 00057)is considered as unsupported

As Marc says in the second paragraph of 1.5.4, "My explanation is
somewhat simplified, as the option-checking rules have evolved from
POSIX1990 to SUS1 to SUS3 into something pretty complicated."

If you want to take the "undefined" and "0" situations into account as
described in POSIX.1-2001 then you either have to target your code at
only POSIX.1-2001 systems, or you have to check _POSIX_VERSION before
deciding what those cases mean.

It's also worth noting that having "undefined" mean the same as "0"
has turned out to cause problems when new options are introduced.
It is going to change to mean the same as "-1" in the next POSIX
revision.

--
Geoff Clare <netnews@gclare.org.uk>

5515159@gmail.com

2006-09-19, 4:00 am

Thank u for your answer! and when u say "It is going to change to mean
the same as "-1" in the next POSIX revision.",what u mean is 'the
undefined situation' will mean the
same as "-1",right?
Another question: i'm now testing marc's
suvreq.c(http://www.basepath.com/aup/ex/suvreq_8c-source.html) on my
debian 3.1 platform .when i remove test macros such as '_POSIX_SOURCE'
and _XOPEN_SOURCE' from the source file,the system gives a very strange
result about which standards it supports:
Request:
_POSIX_SOURCE undefined
_XOPEN_SOURCE undefined
_XOPEN_SOURCE_EXTENDED undefined
Claims:
_POSIX_VERSION = 200112
X/Open
_XOPEN_VERSION = 4

while the posix_version is 200112L ,the default SUS standard is SUS1,I
think the system should be considered supporting POSIX2001 but why the
SUS version is so low and is my decision right?

Geoff Clare wrote:
> "dodo" <5515159@gmail.com> wrote, on Fri, 15 Sep 2006:
>
>
> As Marc says in the second paragraph of 1.5.4, "My explanation is
> somewhat simplified, as the option-checking rules have evolved from
> POSIX1990 to SUS1 to SUS3 into something pretty complicated."
>
> If you want to take the "undefined" and "0" situations into account as
> described in POSIX.1-2001 then you either have to target your code at
> only POSIX.1-2001 systems, or you have to check _POSIX_VERSION before
> deciding what those cases mean.
>
> It's also worth noting that having "undefined" mean the same as "0"
> has turned out to cause problems when new options are introduced.
> It is going to change to mean the same as "-1" in the next POSIX
> revision.
>
> --
> Geoff Clare <netnews@gclare.org.uk>

Geoff Clare

2006-09-19, 8:01 am

5515159@gmail.com wrote, on Tue, 19 Sep 2006:

> Geoff Clare wrote:
>
> when u say "It is going to change to mean
> the same as "-1" in the next POSIX revision.",what u mean is 'the
> undefined situation' will mean the
> same as "-1",right?

Yes.

> Another question: i'm now testing marc's
> suvreq.c(http://www.basepath.com/aup/ex/suvreq_8c-source.html) on my
> debian 3.1 platform .when i remove test macros such as '_POSIX_SOURCE'
> and _XOPEN_SOURCE' from the source file,the system gives a very strange
> result about which standards it supports:
> Request:
> _POSIX_SOURCE undefined
> _XOPEN_SOURCE undefined
> _XOPEN_SOURCE_EXTENDED undefined
> Claims:
> _POSIX_VERSION = 200112
> X/Open
> _XOPEN_VERSION = 4
>
> while the posix_version is 200112L ,the default SUS standard is SUS1,I
> think the system should be considered supporting POSIX2001 but why the
> SUS version is so low and is my decision right?

I don't know whether these values are by accident or by design, but
it doesn't really matter. You can't tell anything from them if you
don't compile with an appropriate feature test macro (_POSIX_SOURCE,
_POSIX_C_SOURCE or _XOPEN_SOURCE) defined. That's because the
standards only dictate the implementation behaviour that conforming
applications will see, and conforming applications are required to
define feature test macro(s) to indicate which version of the
standard they conform to.

Probably the most sensible thing an implementation could do is
leave _POSIX_VERSION undefined if none of the above feature test
macros are defined, and leave _XOPEN_VERSION undefined if
_XOPEN_SOURCE is not defined and _POSIX_C_SOURCE is either
undefined or less than 200112. Unfortunately none of the
implementations I'm familiar with do that.

--
Geoff Clare <netnews@gclare.org.uk>

dodo

2006-09-20, 8:01 am

Thank u,Geoff, for your patience! As I'm reading your answer, i'v just
come to realize that those "POSIX and SUS"standards are NOT as
important as I'v once thought when i first read about them:To write an
app for POSIX-conformance is far from writing an app for unix-like OSes
in the real world: After all,little progress is seen made by
developpers of the open source communities of both OS and
apps.Portabilitise can be achieved by using tools like autoconf. Do you
agree with me?
Geoff Clare wrote:
> 5515159@gmail.com wrote, on Tue, 19 Sep 2006:
>
>
> Yes.
>
>
> I don't know whether these values are by accident or by design, but
> it doesn't really matter. You can't tell anything from them if you
> don't compile with an appropriate feature test macro (_POSIX_SOURCE,
> _POSIX_C_SOURCE or _XOPEN_SOURCE) defined. That's because the
> standards only dictate the implementation behaviour that conforming
> applications will see, and conforming applications are required to
> define feature test macro(s) to indicate which version of the
> standard they conform to.
>
> Probably the most sensible thing an implementation could do is
> leave _POSIX_VERSION undefined if none of the above feature test
> macros are defined, and leave _XOPEN_VERSION undefined if
> _XOPEN_SOURCE is not defined and _POSIX_C_SOURCE is either
> undefined or less than 200112. Unfortunately none of the
> implementations I'm familiar with do that.
>
> --
> Geoff Clare <netnews@gclare.org.uk>

Geoff Clare

2006-09-21, 8:01 am

"dodo" <5515159@gmail.com> wrote, on Wed, 20 Sep 2006:

> Thank u,Geoff, for your patience! As I'm reading your answer, i'v just
> come to realize that those "POSIX and SUS"standards are NOT as
> important as I'v once thought when i first read about them:To write an
> app for POSIX-conformance is far from writing an app for unix-like OSes
> in the real world: After all,little progress is seen made by
> developpers of the open source communities of both OS and
> apps.Portabilitise can be achieved by using tools like autoconf. Do you
> agree with me?

In the context of functions added or deleted between POSIX/SUS revisions
or optional features in POSIX and how to test for them, you may have a
point. If a project is using autoconf anyway (to test for the presence
of things outside the standard, like SDL, GTK, etc.) then it would be
just as easy to have it test for added/deleted/optional standard
interfaces as it would to do it "the POSIX way". For small programs
that can be implemented using only POSIX/SUS interfaces, then personally
I would prefer to avoid using autoconf and the like.

In the wider context of the importance of POSIX/SUS overall, I
completely disagree. They have been the single most important influence
on portability between real world unix-like OSes in the last 15+ years.
(Having said that, I should add a disclaimer that my view may be
somewhat biased. The XPG/POSIX/SUS standards have played a central
part in my working life since 1987.)
[color=darkred]
> Geoff Clare wrote:

--
Geoff Clare <netnews@gclare.org.uk>

Sponsored Links