Prev: Header file for size64_t?
Next: Monitoring file operations of Program
From: kennith.mccune on 16 Jun 2008 02:10
I have a few problems with the single UNIX specification version 3.

I downloaded the HTML version of the specification, and have found it
to be laking in logical/descriptive quality and structural layout.

My main questions are: Do I have the correct standard, i.e. do my
problems correspond to the "real" standard?; Am I just overreacting,
in other words, with experience do these problems just go away?; Is
their a rational reason for the structural and logical problems I have
subsequently complained about?


logical:

./susv3/basedefs/sys/socket.h.html specifies that MSG_CTRUNC is a
valid parameter for the flags parameter of function ./susv3/functions/
sendmsg.html(..., int flags) yet sendmesg(..., int flags) makes no
mention of MSG_CTRUNC; Why does the specification contain a
contradiction by omission? Is the void* dst parameter (the numeric
address) of ./susv3/functions/inet_pton.html actually a ./susv3/
basedefs/netinet/in.h.html#in_addr pointer?

structural:

The function, ./susv3/functions/ntohl.html, does not have any
specification; Presumably it is combined with another function, but
by just looking at the ./susv3/idx/networking.html page there is no
way of learning which function, except by doing a full file search of
all functions for a term matching ntohl; This seems impractical in
terms of both computational resources and logical structure. ./susv3/
idx/networking.html makes no mention of inet_pton or inet_ntoa, the
only way to learn of both is to go to ./susv3/basedefs/arpa/
inet.h.html; So why does ./susv3/idx/networking.html exist?

From: Geoff Clare on 16 Jun 2008 09:08
kennith.mccune wrote:

> I have a few problems with the single UNIX specification version 3.
>
> I downloaded the HTML version of the specification, and have found it
> to be laking in logical/descriptive quality and structural layout.
>
> My main questions are: Do I have the correct standard, i.e. do my
> problems correspond to the "real" standard?; Am I just overreacting,
> in other words, with experience do these problems just go away?; Is
> their a rational reason for the structural and logical problems I have
> subsequently complained about?

The "real" standard is the one in PDF format, or the paper versions
printed from the PDF and published by ISO/IEC, IEEE or The Open Group.
The html version is provided for convenience, but the PDF always
takes precedence.

>
> logical:
>
> ./susv3/basedefs/sys/socket.h.html specifies that MSG_CTRUNC is a
> valid parameter for the flags parameter of function ./susv3/functions/
> sendmsg.html(..., int flags) yet sendmesg(..., int flags) makes no
> mention of MSG_CTRUNC; Why does the specification contain a
> contradiction by omission?

You are reading too much into the statement on the <sys/socket.h> page.
It says:

"The <sys/socket.h> header shall define the following macros, with
distinct integer values, for use as the valid values for the
msg_flags field in the msghdr structure, or the flags parameter in
recvfrom(), recvmsg(), sendmsg(), or sendto() calls:"

and then lists MSG_CTRUNC, MSG_DONTROUTE, MSG_EOR, MSG_OOB, MSG_PEEK,
MSG_TRUNC, and MSG_WAITALL. You are taking this to mean that all of
those macros are used in all of those places, but that isn't what it
says. Perhaps you subconsciously treated the "or" as an "and".

> Is the void* dst parameter (the numeric
> address) of ./susv3/functions/inet_pton.html actually a ./susv3/
> basedefs/netinet/in.h.html#in_addr pointer?

No, it is the actual numeric address, in network byte order (32 bits
for IPv4, 128 bits for IPv6).

> structural:
>
> The function, ./susv3/functions/ntohl.html, does not have any
> specification; Presumably it is combined with another function, but
> by just looking at the ./susv3/idx/networking.html page there is no
> way of learning which function, except by doing a full file search of
> all functions for a term matching ntohl; This seems impractical in
> terms of both computational resources and logical structure.

The files

susv3/functions/ntohs.html
susv3/functions/ntohl.html
susv3/functions/htonl.html
susv3/functions/htons.html

should all be hard links to the same file. It sounds like maybe you
have a broken extraction. (Perhaps you extracted the tar file on a
file system that doesn't support hard links.)

> ./susv3/
> idx/networking.html makes no mention of inet_pton or inet_ntoa, the
> only way to learn of both is to go to ./susv3/basedefs/arpa/
> inet.h.html; So why does ./susv3/idx/networking.html exist?

The topic indexes are an html-only convenience feature. They aren't
part of the "real" standard.

--
Geoff Clare <netnews(a)gclare.org.uk>
 | 
Pages: 1
Prev: Header file for size64_t?
Next: Monitoring file operations of Program