From owner-freebsd-security  Mon Nov 13 13:33:21 1995
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id NAA00501
          for security-outgoing; Mon, 13 Nov 1995 13:33:21 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00468
          ; Mon, 13 Nov 1995 13:33:06 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id IAA07800; Tue, 14 Nov 1995 08:27:52 +1100
Date: Tue, 14 Nov 1995 08:27:52 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511132127.IAA07800@godzilla.zeta.org.au>
To: davidg@Root.COM, peter@jhome.dialix.com
Subject: Re: cvs commit: CVSROOT log_accum.pl
Cc: ache@astral.msk.su, committers@freebsd.org, security@freebsd.org
Sender: owner-security@freebsd.org
Precedence: bulk

>BTW: I suspect "struct ucred" should be reordered for better internal 
>alignment..  
>It is currently:
>struct ucred {
>  short cr_ref;
>  long  cr_uid;
>  short cr_ngroups;
>  long  cr_groups[NGROUPS];
>}

Actually, it is currently:

struct ucred {
  u_short cr_ref;
  ^^
  uid_t  cr_uid;
  ^^^^^
  short cr_ngroups;
  gid_t  cr_groups[NGROUPS];
  ^^^^^
}

uid_t and gid_t just happen to be unsigned long.  This is bogus.  They
are u_int32_t in NetBSD.  I think they should be machine dependent and
normally u_int if u_int has more than 32 bits, otherwise u_long.

>The order of cr_ngroups and cr_uid could be swapped making the whole 
>thing 4 bytes smaller (assuming that I understand structure packing.. :-)

You can't tell the best packing in general.  Putting the explicit char,
short, int and long types at the beginning of the struct is probably
best in general and works well here.

Bruce