From owner-svn-src-head@FreeBSD.ORG Tue Feb 4 07:02:27 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09F9E3B9; Tue, 4 Feb 2014 07:02:27 +0000 (UTC) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 56D0A1A13; Tue, 4 Feb 2014 07:02:26 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id C5ABFD40986; Tue, 4 Feb 2014 17:29:28 +1100 (EST) Date: Tue, 4 Feb 2014 17:29:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Eitan Adler Subject: Re: svn commit: r261454 - head/lib/libc/net In-Reply-To: <201402040301.s1431XgK027156@svn.freebsd.org> Message-ID: <20140204164703.S1229@besplex.bde.org> References: <201402040301.s1431XgK027156@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=HZAtEE08 c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=Gbr0sxjGmr4A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=4jIg5_e19IMA:10 a=thoglojNH_oWOjbN14wA:9 a=vSSvafM5ynuK-452:21 a=D64CJz4_VERPXX-9:21 a=CjuIK1q_8ugA:10 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 07:02:27 -0000 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 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. Bruce