Pelles C forum
Pelles C => Bug reports => Topic started by: andi.martin on December 15, 2008, 09:32:41 PM
-
Hi Pelle,
IMHO there is a bug. Following code shows the problem:
#include <stdio.h>
#include <stddef.h>
#include <windows.h>
int main(int argc, char *argv[])
{
DCB dcb={sizeof(DCB)};
HANDLE h = CreateFileA("COM1:", GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
GetCommState(h, &dcb);
printf("ByteSize is at offset %d\n", offsetof(DCB, ByteSize)); // 22 (and should be 18)
printf("ByteSize is %d\n", dcb.ByteSize); // 0
dcb.XonLim=20;
if(!SetCommState(h, &dcb))
{
printf("Error where none should be...\n");
}
CloseHandle(h);
return 0;
}
Kindly regards,
Andreas Martin
-
Workaround:
You have to change line 821 (winbase.h) from
DWORD fDummy2:17;
to
DWORD fDummy2:16;
to make it work.
Regards,
Andreas
-
Searched backwards to find PellesC version 4.50 which hasn't that bug yet.
Regards,
Andreas
-
Hi Pelle,
I think it's ANSIC anyway and not a bug, since alignment of bit-field members and non-bit-field members is in any point of view implementation defined or unspecified:
Ref: ISO/IEC 9899:1999 (E), 6.7.2.1 Structure and union specifiers (10-12)
Following example shows that in "struct s2" 4 bytes are "wasted", because no bitfield exceeds 4 bytes (32 bits).
Well that's still not a bug.
But poorly windows headers expect a compiler to leave only unused (bit) space appropriate to units type. That previous DCB structure sample is a good example, others might be found...
#include <stdio.h>
#include <stddef.h>
typedef struct s1 {
int a:15;
int b:16;
char c;
};
typedef struct s2 {
int a:16;
int b:16;
char c;
};
int main(int argc, char *args[])
{
printf("%d\n", offsetof(struct s1, c)); // "4"
printf("%d\n", offsetof(struct s2, c)); // "8"
return 0;
}
Kindly regards,
Andreas Martin
-
This sounds like the same bug I found, a few days ago, in a different context - I will check the fix with your code too...