>
> Here's the struct:
>
> struct NDXHeader
> {
> sal_uInt32 db_rootpage; /* Rootpage position
> */
> sal_uInt32 db_pagecount; /* Page count
> */
> sal_uInt8 db_frei[4]; /* Reserved
> */
> sal_uInt16 db_keylen; /* Key length
> */
> sal_uInt16 db_maxkeys; /* Maximum number of keys per
> page */
> sal_uInt16 db_keytype; /* Type of key:
> 0 = Text
> 1 = Numerical
> */
> sal_uInt16 db_keyrec; /* Length of an index record
> RecordNumber + keylen
> */
> sal_uInt8 db_frei1[3]; /* Reserved
> */
> sal_uInt8 db_unique; /* Unique
> */
> char db_name[488]; /* index_name (field name)
> */
> };
>
> sal_uIntXX are LibreOffice internal #define for the unsigned integer
> type of size XX bits. I find it rather unlikely they would differ
> across the LibreOffice codebase; if they do, we have a "bigger"
> problem.
>
> What do you think about this conjecture: maybe gcc compiles the
> structure with different alignment in different contexts? (Possibly
> because the LibreOffice build system forces it to with compiler flags?)
I have seen similar problem of warning in betwen units because one was compiled
with -fsigned-char and other with -funsigned-char (in Firefox). I think
compiler is
valid to warn here about ODR violation since those flags are ABI breaking flags.
It is also possible it is compare bug in the new ODR checking code - but I do
not
really see how it could get confused in such a rather simple structure.
>
> > Currently GCC report just topelvel type difference, I have patch for
> > the ODR merging that reports the inner type too. I will try to
> > update it for mainline today or tomorrow and get back to you.
>
> Great, thanks. I'm waiting for the result with great curiosity.
Yep, I am curious too. I just got my trees updated after vacation so hopefully
I will get there soon (for sure libreoffice will trigger few GCC bugs first)
Honza
>
> --
> Lionel
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
