Date: Tue, 4 Feb 2014 17:29:27 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Eitan Adler <eadler@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r261454 - head/lib/libc/net Message-ID: <20140204164703.S1229@besplex.bde.org> In-Reply-To: <201402040301.s1431XgK027156@svn.freebsd.org>
index | next in thread | previous in thread | raw e-mail
On Tue, 4 Feb 2014, Eitan Adler wrote: > Log: > libc/net: Fix some issues in inet6_opt_init() (from RFC 3542): > > * The RFC says (in section 10.1) that only when extbuf is not NULL, > extlen shall be checked, so don't perform this check when NULL is > passed. > > * socklen_t is unsigned, so checking extlen for less than zero is > not needed. Why be so unportable? socklen_t is not necessarily unsigned. It should be signed, and was signed int in BSD, but was broken during development of POSIX.1-2001. FreeBSD apparently tracked the buggy development version and changed from int to u_int32_t in 1999. >From POSIX.1-2001-draft7: 12409 The <sys/socket.h> header shall define the type socklen_t, which is an integer type of width of 12410 at least 32 bits; see APPLICATION USAGE. [APPLICATION USAGE "recommends" that values stored in socklen_t not be larger than 2**31-1. It doesn't spell out that this is because socklen_t might be a signed type. Note that "width" is a technical tyem for integer types, and is satisfied by signed 32-bit ints although these have only 31 useful bits.] 7456 B.2.10.6 Socket Types 7457 The type socklen_t was invented to cover the range of implementations seen in the field. The 7458 intent of socklen_t is to be the type for all lengths that are naturally bounded in size; that is, that 7459 they are the length of a buffer which cannot sensibly become of massive size: network addresses, 7460 host names, string representations of these, ancillary data, control messages, and socket options [2**31-1 is massive. 2**16-1 would just be a bit too small.] 7461 are examples. Truly boundless sizes are represented by size_t as in read( ), write( ), and so on. [Nonsense. 2**31-1 is massive for read/write buffer sizes too, and size_t is far from being able to represent truly boundless sizes.] 7462 All socklen_t types were originally (in BSD UNIX) of type int. During the development of 7463 IEEE Std 1003.1-200x, it was decided to change all buffer lengths to size_t, which appears at face 7464 value to make sense. When dual mode 32/64-bit systems came along, this choice unnecessarily 7465 complicated system interfaces because size_t (with long) was a different size under ILP32 and 7466 LP64 models. Reverting to int would have happened except that some implementations had 7467 already shipped 64-bit-only interfaces. The compromise was a type which could be defined to be 7468 any size by the implementation: socklen_t. It was too late to fix the breakage for read/write. It was not too late to require plain int again for socklen_t. POSIX.1 requires 32-bit ints, so int for socklen_t was large enough. Strangely, POSIX only requires 16 bits for size_t and ssize_t. This makes some sense since it allows API's burdened by using typedefed types to use the best machine-dependent type (portable applications have the burden of using the typedefed types no matter what the implementation chooses). OTOH, if the API uses a basic type like int, then it has to be large enough to work for all implementations, so int can't be 16 bits. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140204164703.S1229>