Re: tsearch2 portability bug

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: tsearch2 portability bug
Date: 2005-01-11 11:10:00
Message-ID: Pine.GSO.4.61.0501111401300.8559@ra.sai.msu.su
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

we think we could return to this issue later, because doing such change
without careful testing would be risky. Of course, it's attractive
to combine changes with upcoming release, because people would
initdb in anyway, but currently we couldn't give enough
attention to testing.

Oleg

On Mon, 10 Jan 2005, Tom Lane wrote:

> 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
> {
> uint16
> weight:2,
> pos:14;
> } 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 6.7.2.1:
>
> [#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
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Darcy Buskermolen 2005-01-11 16:04:48 IBM releases 500 patents
Previous Message Rangarajan 2005-01-11 09:08:10 Bugs