Thread

1. Re: [HACKERS] acl problem in NetBSD/m68k

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-06-29T04:46:03Z

   Tatsuo Ishii <t-ishii@sra.co.jp> writes:
   >> I do not like this patch at *all*.  Why is sizeof(AclItem) not the
   >> correct thing to use?
   
   > In NetBSD/m68k sizeof(AclItem) = 6, not 8.
   
   Oh, I see: the struct contains int32, uint8, uint8, and so it will
   be padded to a multiple of int32's alignment requirement --- which
   is 4 most places but only 2 on m68k.
   
   >> Perhaps the real problem is that the AclItem struct definition needs
   >> modification?  Or maybe we need a way to put a machine-dependent size
   >> into the pg_type entry for type aclitem?  The latter seems like a
   >> good thing to be able to do on general principles.
   >
   > Glad to hear you have better idea. Anyway, NetBSD/m68k users need some 
   > way to fix the problem now, since the problem seems very serious.
   
   There are two ways we could attack this: (1) put a "pad" field into
   struct AclItem (prolly two uint8s) to try to ensure that compilers
   would think it is 8 bytes long, or (2) make the size field for aclitem
   in pg_type.h read "sizeof(AclItem)".  I think the latter is a better
   long-term solution, because it eliminates having to try to guess
   what a compiler will do with a struct declaration.  But there are
   several possible counterarguments:
   
   * It might require patching the scripts that read pg_type.h --- I
   am not sure if they'd work unmodified.
   
   * We'd either need to #include acl.h into pg_type.h or push the
   declarations for AclItem into some more-widely-used header.
   
   * In theory this would represent an initdb change and couldn't
   be applied before 6.6.  In practice, Postgres isn't working right
   now on any platform where sizeof(AclItem) != 8, so initdb would
   *not* be needed for any working installation.
   
   I don't think any of these counterarguments is a big deal, but
   maybe someone else will have a different opinion.
   
   			regards, tom lane
   
   

2. Re: [HACKERS] acl problem in NetBSD/m68k

   Bruce Momjian <maillist@candle.pha.pa.us> — 1999-06-29T05:07:33Z

   > There are two ways we could attack this: (1) put a "pad" field into
   > struct AclItem (prolly two uint8s) to try to ensure that compilers
   > would think it is 8 bytes long, or (2) make the size field for aclitem
   > in pg_type.h read "sizeof(AclItem)".  I think the latter is a better
   > long-term solution, because it eliminates having to try to guess
   > what a compiler will do with a struct declaration.  But there are
   > several possible counterarguments:
   > 
   > * It might require patching the scripts that read pg_type.h --- I
   > am not sure if they'd work unmodified.
   > 
   > * We'd either need to #include acl.h into pg_type.h or push the
   > declarations for AclItem into some more-widely-used header.
   > 
   > * In theory this would represent an initdb change and couldn't
   > be applied before 6.6.  In practice, Postgres isn't working right
   > now on any platform where sizeof(AclItem) != 8, so initdb would
   > *not* be needed for any working installation.
   > 
   > I don't think any of these counterarguments is a big deal, but
   > maybe someone else will have a different opinion.
   
   My guess is that we are looking at different solutions for 6.5.1 and
   6.6.  A good argument for a source tree split.
   
   Currently, initdb runs through pg_type.h using sed/awk, so it can't
   see any of the sizeof() defines.  One hokey solution would be to have
   the compile process run a small C program that dumps out the acl size
   into a file, and have initdb pick up that.  That is a terrible solution,
   though.  I guess we don't have any other 'struct' data types that need
   to know the size of the struct on a give OS.  Maybe padding with an
   Assert() to make sure it stays at the fixed size we specify is a good
   solution.
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   
   

3. Re: [HACKERS] acl problem in NetBSD/m68k

   Brian E Gallew <geek+@cmu.edu> — 1999-06-29T14:52:34Z

   Then <maillist@candle.pha.pa.us> spoke up and said:
   > > There are two ways we could attack this: (1) put a "pad" field into
   > > struct AclItem (prolly two uint8s) to try to ensure that compilers
   > > would think it is 8 bytes long, or (2) make the size field for aclitem
   > > in pg_type.h read "sizeof(AclItem)".  I think the latter is a better
   > > long-term solution, because it eliminates having to try to guess
   > > what a compiler will do with a struct declaration.  But there are
   > > several possible counterarguments:
   > 
   > Currently, initdb runs through pg_type.h using sed/awk, so it can't
   > see any of the sizeof() defines.  One hokey solution would be to have
   > the compile process run a small C program that dumps out the acl size
   > into a file, and have initdb pick up that.  That is a terrible solution,
   > though.  I guess we don't have any other 'struct' data types that need
   > to know the size of the struct on a give OS.  Maybe padding with an
   > Assert() to make sure it stays at the fixed size we specify is a good
   > solution.
   
   Perhaps it would be easier to pipe the output of cpp on pg_type.h thru
   the awk/sed script?  This would have the added advantage of making
   other system-dependent changes to pg_type.h easier.
   
   -- 
   =====================================================================
   | JAVA must have been developed in the wilds of West Virginia.      |
   | After all, why else would it support only single inheritance??    |
   =====================================================================
   | Finger geek@cmu.edu for my public key.                            |
   =====================================================================