From owner-freebsd-arch@FreeBSD.ORG Wed Jan 8 20:24:17 2014 Return-Path: Delivered-To: freebsd-arch@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 7EAEA5A9; Wed, 8 Jan 2014 20:24:17 +0000 (UTC) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 295071EAD; Wed, 8 Jan 2014 20:24:17 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id 5so2184576qeb.6 for ; Wed, 08 Jan 2014 12:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iRDiSvhpCRTYuAw86kjHNenik3paurjvs7XTOQkr/nQ=; b=h/o7to9wXrGpWSE5mUyC1rZIUCB+XRry/5A5mRpkM8BPlu4kkQGPJy5lnYNDnjtcS2 NzeoEODf7zAUkLBVH8XmlV9ojcylggAqz15vWcvsISyigp1dsMgAK1jeMPwVZvZMbmfT Yr1i/x4QKUCCJGy5NduyZzTKsY1T19DH2HgT245QR/ND84O3ucbpouJF5IQLFeupE4LW PTtwIIEDIvk7ZqcUvjleGpxp04hJnZ5Z1ECF4kmt+Oxh7Jfa+ntj9xl7pZKVr6u9GRZR FHeNTHwWqOxbirSb6qJo53ZF3kY41IImNJQniCE7QpRCERcbaQrncgaXIsFwAzcKGN6h v8gg== MIME-Version: 1.0 X-Received: by 10.49.30.197 with SMTP id u5mr19157251qeh.33.1389212656400; Wed, 08 Jan 2014 12:24:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Wed, 8 Jan 2014 12:24:16 -0800 (PST) In-Reply-To: <20140108152632.L969@besplex.bde.org> References: <9C1291B5-215B-440E-B8B0-6308840F755C@bsdimp.com> <5821DA91-E9C7-4D1A-A108-63E74CFF1FC5@bsdimp.com> <20140108152632.L969@besplex.bde.org> Date: Wed, 8 Jan 2014 12:24:16 -0800 X-Google-Sender-Auth: qP6ioxbfCisQ3ctVDCcfpraPMM0 Message-ID: Subject: Re: Using sys/types.h types in sys/socket.h From: Adrian Chadd To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Bruce Evans , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:24:17 -0000 On 7 January 2014 20:48, Bruce Evans wrote: > This API has many design errors and style bugs, but ints for file > are the least serious of them. int is the same as int32_t on all supported > arches, so the uint32_t is not in the middle, but gives perfect packing to > a 64-bit boundary of the int before it. In fact, everything is packed: > > 32-bit arches: 64-bit arches: > 32-bit int 32-bit int > 32-bit u_int 32-bit u_int > 32-bit pointer 64-bit pointer > 32-bit u_int holding ptr 64-bit u_int holding pointer > > Style(9) specifies sorting by size first (it actually mean by alignment > first). That is not very easy since the size^Walignment of typedefed > types should be opaque. In practice, assuming what it is mostly gives > correct results. It gives exactly the opposite of the above: > > N-bit u_int holding ptr > M-bit pointer /* assume M <= N and alignment == size */ > 32-bit u_int (can spell it u_int, not uint32_t, to pack better with int) > 32-bit int /* assume plain int gives this */ So: /* * sendfile(2) kqueue information */ struct sf_hdtr_kq { uintptr_t kq_ident; /* ident (from userland?) */ void *kq_udata; /* user data pointer */ uint32_t kq_flags; /* extra flags to pass in */ int kq_fd; /* kq fd to post completion events on */ }; ? > Types that usually have the same size should be sorted on rank, although > style(9) doesn't say this (see the C99 standard for a formal definition > of 'rank'). This gives int before long, although on i386 int has the > same size as long. It takes an exotic unsupported arch for types of > smaller rank to have larger size/ alignment. This also gives int > before u_int, although int has the same size as u_int on all supported > arches. So, C99 section 6.3.1.1 ? (from http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf) > After assuming that plain int has >= 32 bits, we can assume this for the > flags arg too, to get at least 32 bits from it. This minimizes assumptions > mad in packing. Using int32_t instead of int for file descriptors would > be a slightly worse way of assuming that ints are never expanded from 32 > bits. *nod* Thanks! -a