winbindd 32/64 offset issues

[Herb Lewis]

maybe we could do something like bsd does in stat.h

struct timespec st_birthtimespec; /* time of file creation */
/*
  * Explicitly pad st_birthtimespec to 16 bytes so that the size of
  * struct stat is backwards compatible.  We use bitfields instead
  * of an array of chars so that this doesn't require a C99 compiler
  * to compile if the size of the padding is 0.  We use 2 bitfields
  * to cover up to 64 bits on 32-bit machines.  We assume that
  * CHAR_BIT is 8...
  */
unsigned int :(8 / 2) * (16 - (int)sizeof(struct timespec));
unsigned int :(8 / 2) * (16 - (int)sizeof(struct timespec));


Jim McDonough wrote:
> Jerry,
> Despite your comments about testing with 32bit libs on 64bit platforms in
> the winbindd_request struct in winbindd_nss.h, it seems we're out of sync,
> and the following comment may be part of the issue:
> 
> nsswitch/winbindd_nss.h:40
> -------
> /* Have to deal with time_t being 4 or 8 bytes due to structure alignment.
>   On a 64bit Linux box, we have to support a constant structure size
>   between /lib/libnss_winbind.so.2 and /li64/libnss_winbind.so.2.
>   The easiest way to do this is to always use 8byte values for time_t. */
> ------
> 
> I can say that I've recently found this to not be true.  On multiple
> platforms (RHEL4 at a customer site, ubuntu Edgy on my laptop right now),
> the stabs output shows the extra_data union (containing the SMB_TIME_T for
> alignment) to start at 16544 bits offset, which is 2068 bytes..._not_ a
> multiple of 8.  This is on 3.0.25...on 3.0.26 there is an extra enum 
> earlier
> that hides this problem, I think.  I tried several approaches, but there is
> simply not a guarantee on a 32-bit platform that anything I tried is going
> to be aligned on an 8-byte boundary.
> 
> The only solution I found was the old method that hasn't been updated in 
> the
> code in a while...the padding member of the huge data union needs to be set
> to that 8-byte boundary, and still, since that data union isn't guaranteed
> to be on an 8-byte boundary to start, we have to really just look at the
> offset in stabs output and see if each union lines up between 
> architectures.
> 
> Or we could just start up that marshalling discussion again :-)
> 
> In any case, before I check anything in, can someone run any quick tests of
> your various binaries on 64-bit platforms using 32-bit winbind libs?
>