Re: [HACKERS] acl problem in NetBSD/m68k
От | Brian E Gallew |
---|---|
Тема | Re: [HACKERS] acl problem in NetBSD/m68k |
Дата | |
Msg-id | emacs-smtp-26313-14200-56754-330647@export.andrew.cmu.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] acl problem in NetBSD/m68k (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
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. | =====================================================================
В списке pgsql-hackers по дате отправления: