On Mon, Apr 1, 2013 at 9:06 PM, Ted Unangst wrote:
> My (admittedly weak) rationale is that if a struct contains a field, I
> would
> like to be able to declare local variables of the same type as that field.
> And I don't want my local variables in my code to be using __int types.
>
In the spec
On Mon, Apr 01, 2013 at 20:40, Philip Guenther wrote:
>> There won't be any side effects from using __uint64_t, but I think of it
>> more like a building block for another type. Not to be used directly.
>>
>
> Disagree. Indeed, I just committed James's diff (plus one additional
> change to CMSG_
On Mon, Apr 1, 2013 at 8:35 PM, Ted Unangst wrote:
> On Mon, Apr 01, 2013 at 22:54, James Turner wrote:
> > I've come across a piece of software that defines __POSIX_C_SOURCE which
> > causes __BSD_VISIBLE to bet set to 0.
> >
> > In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included ins
On Mon, Apr 01, 2013 at 22:54, James Turner wrote:
> I've come across a piece of software that defines __POSIX_C_SOURCE which
> causes __BSD_VISIBLE to bet set to 0.
>
> In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead
> of sys/types.h. This is fine however in three cases we
I've come across a piece of software that defines __POSIX_C_SOURCE which
causes __BSD_VISIBLE to bet set to 0.
In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead
of sys/types.h. This is fine however in three cases we reference
u_int8_t (2) and u_int64_t (1) which requires sys/t