Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] acl problem in NetBSD/m68k

From: Brian E Gallew <geek+(at)cmu(dot)edu>
To: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] acl problem in NetBSD/m68k
Date: 1999-06-29 14:52:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Then <maillist(at)candle(dot)pha(dot)pa(dot)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(at)cmu(dot)edu for my public key.                            |

In response to

pgsql-hackers by date

Next:From: Thomas LockhartDate: 1999-06-29 15:28:08
Subject: Re: [HACKERS] Perl library (was Building Postgres)
Previous:From: Brian E GallewDate: 1999-06-29 14:49:26
Subject: Re: [HACKERS] Perl library (was Building Postgres)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group