Thread: tsearch2 portability bug

tsearch2 portability bug

From
Tom Lane
Date:
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


Re: tsearch2 portability bug

From
Oleg Bartunov
Date:
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