Yet more tsearch refactoring

Heikki Linnakangas wrote:

* Defined new struct WordEntryPosVector that holds a uint16 length and a
variable size array of WordEntries. This replaces the previous
convention of a variable size uint16 array, with the first element
implying the length. WordEntryPosVector has the same layout in memory,
but is more readable in source code. The POSDATAPTR and POSDATALEN
macros are still used, though it would now be more readable to access
the fields in WordEntryPosVector directly.

Did you check it on 64-bit boxes with strict alignment? I remember that was a
headache for me.

--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

Teodor Sigaev wrote:

Heikki Linnakangas wrote:

* Defined new struct WordEntryPosVector that holds a uint16 length and a
variable size array of WordEntries. This replaces the previous
convention of a variable size uint16 array, with the first element
implying the length. WordEntryPosVector has the same layout in memory,
but is more readable in source code. The POSDATAPTR and POSDATALEN
macros are still used, though it would now be more readable to access
the fields in WordEntryPosVector directly.

Did you check it on 64-bit boxes with strict alignment? I remember that
was a headache for me.

No, I didn't. But I don't see how it would make a difference, the
resulting memory layout is the same AFAICS.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

"Teodor Sigaev" <teodor@sigaev.ru> writes:

Did you check it on 64-bit boxes with strict alignment? I remember that was a
headache for me.

Is there a regression test which would fail if this kind of problem crops up?
Not every developer can test every type of hardware but (aside from believing
the code will work of course) we should at a minimum be certain that the build
farm will detect the problem.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com