Should include files be bug for bug compatible?

[Dylan Smith]

In richedit.h CHARFORMAT2[AW] is padded differently on the Windows
PSDK depending on whether it is included for a c or c++ source file.

Should the include file be fixed, or does bug for bug compatibility
mean that a correct CHARFORMAT2 structure should be declared in a
private include file?

I tried compiling the following test program using the PSDK:

/* source code */
#include <stdio.h>
#include <windows.h>
#include <richedit.h>
int main()
{
    printf("sizeof(CHARFORMAT2W) %d\n",
    sizeof(CHARFORMAT2W));
    printf("FIELD_OFFSET(CHARFORMAT2W, wWeight) %d\n",
    FIELD_OFFSET(CHARFORMAT2W, wWeight));
    printf("FIELD_OFFSET(CHARFORMAT2W, sSpacing) %d\n",
    FIELD_OFFSET(CHARFORMAT2W, sSpacing));
    return 0;
}
/* end of code */

The compiled c version gives the following output:
sizeof(CHARFORMAT2W) 116
FIELD_OFFSET(CHARFORMAT2W, wWeight) 90
FIELD_OFFSET(CHARFORMAT2W, sSpacing) 92

The c++ version gives the following output:
sizeof(CHARFORMAT2W) 116
FIELD_OFFSET(CHARFORMAT2W, wWeight) 92
FIELD_OFFSET(CHARFORMAT2W, sSpacing) 94

Those are the only two fields that are affected, so the inconsistency
has gone unnoticed until now.

According to the About Rich Edit Controls page
(http://msdn.microsoft.com/en-us/library/bb787873(VS.85).aspx)%C2%A0Windows
has used a C++ code base since richedit 2.0, and so all the richedit
DLLs should follow the c++ version of CHARFORMAT2 since riched32.dll
is just a wrapper around riched20.dll for richedit 1.0 emulation.
Wine's include file will compile like the c version, which caused some
weird behaviour that I noticed when improving the EM_SETCHARFORMAT
tests.

[Alexandre Julliard]

Dylan Smith  writes:
> In richedit.h CHARFORMAT2[AW] is padded differently on the Windows
> PSDK depending on whether it is included for a c or c++ source file.
>
> Should the include file be fixed, or does bug for bug compatibility
> mean that a correct CHARFORMAT2 structure should be declared in a
> private include file?

It's OK to fix the include to reflect what the actual dll expects, as
determined by test cases. The test cases themselves will have to work
around it so that they can work with either header.