Thomas Narten wrote:
>I'm asking about the second. I wonder, for example, whether someone
>familiar with the POSIX/Austin Group work has reviewed the document.
>My concern is that there may be some fairly trivial inconsistencies
>with this document and the basic API. It would be nice to try and fix
>those (if they exist). Can anyone speak to this point?
So I took a look at 2292bis-07. Please note I am not speaking
on behalf of posix/austin group, but rather simply as someone
who has been witness to the standardization efforts there.
I reviewed primarily for alignment with 2553bis and the latest
posix/austin standard. I did not review, for example, correctness
of constant values and data structures for match against IPv6
protocol RFCs (hopefully there have already been enough eyes
that have done that).
Some comments for alignment with the latest POSIX standard:
- I suggest you update the Posix references, using the same
reference as 2553bis, which I show below (note the spec has
now also been approved by ISO):
IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX)
Open Group Technical Standard: Base Specifications, Issue 6
December 2001
ISO/IEC 9945-1:2002, 9945-2:2002, 9945-3:2002, 9945-4:2002
Information technology -- Portable Operating System
Interface (POSIX) -- Parts 1, 2, 3 and 4
http://www.opengroup.org/austin
- protocol family constants (PF_xxx) are not defined in this
latest POSIX standard, replace all PF_xxx with AF_xxx
(e.g. PF_INET -> AF_INET)
- section 21.1 shows msg_iovlen as type size_t,
the latest POSIX defines msg_iovlen as type int
Some editorial comments:
- section 7.1 in this sentence, CMSG_LEN should be CMSG_SPACE (see
the nice diagram on page 67, an "ancillary data object" includes
the padding at the end)
"When the application uses
ancillary data it must pass the returned length to CMSG_LEN() to
determine how much memory is needed for the ancillary data object
(including the cmsghdr structure)."
- section 8 typo in first paragraph last sentence "Hob-by-Hop"
- section 10.5 inet6_opt_next, the statement "Typep points the option
type field" does not seem right, for typep to point to the option
type field, it would have to be passed as 'uint8_t **typep'; I think
you mean it points to a buffer into which the option type is stored,
or using wording similar to lenp, "typep stores the option type"
- section 11.1 you should cite one or more references upon which
this statement is based:
"Also, path MTU discovery for multicast has severe scalability
limitations and should thus be avoided by default."
- the data type usage in the example code could be cleaner, for example
in section 22 page 72:
int extlen;
int cmsglen;
extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3);
cmsglen = CMSG_SPACE(extlen);
inet6_rth_space() returns a size_t into int extlen.
int extlen is passed to CMSG_SPACE which expects unsigned int.
CMSG_SPACE returns unsigned int into int cmsglen.
and so on.
A minor technical comment:
- There is an inconsistency in the inet6_opt_set_val and
inet6_opt_get_val functions. In both functions, the offset
argument is type size_t, but the function return value (also
an offset) is type int. Given the intended usage of these
functions, where the return value of one call can be used as
the offset argument on the next call, the data type of the
offset argument should be type int.
I also want to point out an issue that might be raised if this
API is ever brought to the Austin group (IEEE/OpenGroup/ISO) for
standardization. The functions and macros listed below use a variety
of data types for things that represent a "size", including int,
unsigned int, and size_t. All these items, or at least those of
type size_t, could instead be of type socklen_t. Note that some
of the items identified are for use with msg_controllen and cmsg_len,
which are type socklen_t.
Here is the rationale for socklen_t from the latest POSIX standard:
The type socklen_t was invented to cover the range of
implementations seen in the field. The intent of socklen_t
is to be the type for all lengths that are naturally bounded
in size; that is, that they are the length of a buffer which
cannot sensibly become of massive size: network addresses,
host names, string representations of these, ancillary data,
control messages, and socket options are examples. Truly
boundless sizes are represented by size_t as in read(),
write(), and so on.
All socklen_t types were originally (in BSD UNIX) of type int.
During the development of IEEE Std 1003.1-2001, it was decided
to change all buffer lengths to size_t, which appears at face
value to make sense. When dual mode 32/64-bit systems came along,
this choice unnecessarily complicated system interfaces because
size_t (with long) was a different size under ILP32 and LP64 models.
Reverting to int would have happened except that some implementations
had already shipped 64-bit-only interfaces. The compromise was a
type which could be defined to be any size by the implementation:
socklen_t.
The following items could be of type socklen_t:
- inet6_rth_space
- return type
- inet6_rth_init
- bp_len argument
- inet6_opt_init
- return type (but what about error return?)
- extlen argument
- inet6_opt_append
- return type (but what about error return?)
- extlen, prevlen, len arguments
- inet6_opt_finish
- return type (but what about error return?)
- extlen, prevlen arguments
- inet6_opt_set_val
- return type
- offset, vallen arguments
- inet6_opt_next
- return type
- extlen, prevlen, lenp arguments
- inet6_opt_find
- return type
- extlen, prevlen, lenp arguments
- inet6_opt_get_val
- return type
- offset, vallen arguments
- CMSG_SPACE
- return type could be socklen_t to match msg_controllen
- argument type could also be socklen_t
- CMSG_LEN
- return type could be socklen_t to match cmsg_len type
- argument type could also be socklen_t
Short of a changing all of these to socklen_t, we should at least
consider changing the occurances of the size_t type to either
socklen_t or int or unsigned int. This would avoid the complications
raised by size_t on systems having to support both ILP32 and LP64 models.
- Jack
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
