tsearch2 portability bug
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
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@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83