Using sys/types.h types in sys/socket.h

[Adrian Chadd]

On 7 January 2014 20:48, Bruce Evans <brde at 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