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

tsearch2 portability bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: tsearch2 portability bug
Date: 2005-01-11 02:46:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I looked into why the "penguin" buildfarm machine is showing bad
failures on the tsearch2 regression test.  It turns out that the
compiler on that machine considers this struct declaration:

typedef struct
}   WordEntryPos;

to have size/alignment 4, whereas the tsearch2 code has hard-wired
assumptions that the struct will have size/alignment 2.

I believe that the compiler is within its rights to do this, since
the C standard says that the storage unit within which bit-fields
are placed is implementation-defined.  In fact, I believe that the
above struct declaration is a flat-out violation of C99

       [#8]  A  bit-field  shall have a type that is a qualified or
       unqualified version of _Bool, signed int, or  unsigned  int.

There's nothing there that says you can declare it as short int.

I suspect the most practical way of attacking this is to redefine
WordEntryPos as typedef'd to uint16, and provide macros to store
and fetch the two fields via bitwise operations.  I don't have
time to do that right now, and it's probably too late for 8.0 anyway,
unless we want to say that as contrib code tsearch2 is not subject
to RC constraints.

Another little problem is that we cannot emulate the old storage
layout exactly since we don't know which way a given compiler
would have packed the fields.  Therefore, making this change would
arguably require initdb, at least for those as are using tsearch2.

Thoughts anyone?

			regards, tom lane


pgsql-hackers by date

Next:From: Marc G. FournierDate: 2005-01-11 06:10:28
Subject: RC5 Bundled ...
Previous:From: Brendan JurdDate: 2005-01-11 00:02:28
Subject: Re: Verbosity of column definition mismatch error

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