Date: Wed, 8 Jan 2014 12:24:16 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Bruce Evans <bde@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Using sys/types.h types in sys/socket.h Message-ID: <CAJ-VmonemTxS6zvdGU_SvOtnV3bzJ-rKtJcrTEfJ_NY3u7kndA@mail.gmail.com> In-Reply-To: <20140108152632.L969@besplex.bde.org> References: <CAJ-Vmo=MWPQWfP9duWPPwaKee5Zp9Gemj3GKqE8=bxkjn_1YYA@mail.gmail.com> <9C1291B5-215B-440E-B8B0-6308840F755C@bsdimp.com> <CAJ-Vmom3FQOb1ZQTwbmbSiT90N6tmKOoPg8JPQAapkJg2TXqFA@mail.gmail.com> <5821DA91-E9C7-4D1A-A108-63E74CFF1FC5@bsdimp.com> <20140108152632.L969@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 January 2014 20:48, Bruce Evans <brde@optusnet.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonemTxS6zvdGU_SvOtnV3bzJ-rKtJcrTEfJ_NY3u7kndA>