SEQUENCE breaks IFWINTY at x64

[Jugoslav_Dujic]

SEQUENCE seems to break Win32 structures with "holes" within, due to misalignment (because it comes down to !DEC$PACK:1). While there wasn't many such structures at Win32 (DEVMODE, if I recall correctly), there are probably more on x64, due to promotion of several Win32 types to 64-bits. Let us consider T_MSG:

[fortran]     TYPE T_MSG
     SEQUENCE
       integer(HANDLE) hwnd ! handles  HWND 
       integer(UINT) message ! knowns  UINT 
       integer(fWPARAM) wParam ! typedefs  WPARAM 
       integer(fLPARAM) lParam ! typedefs  LPARAM 
       integer(DWORD) time ! knowns  DWORD 
       TYPE (T_POINT) pt ! typedefs  POINT 
     END TYPE
[/fortran]

HANDLE, WPARAM and LPARAM are 8 each, but UINT is 4. The members should be naturally aligned, thus there should be a 4-byte hole between message and wParam. SEQUENCE, however, fills that hole, producing an unusable structure.

It's really tough to say how many such types are broken now. The simplest solution seems to remove SEQUENCE completely -- why was it added at all to Win32 types? If for enabling COMMON (as I vaguely recall), it is not a particularly useful concept in Windows programming, and now it seems to strike back with a vengeance.

[Steven_L_Intel1]

Not quite. When we build IFWINTY, it is compiled with /align:sequence. You'll encounter a problem like this if you declare your own copy. SEQUENCE is added because otherwise the language restricts where you can put a variable of a non-sequence type and it disables reordering (not that we do that). Now we could use BIND(C) for most of these types, but we're not going to go back and recode them.

[Jugoslav_Dujic]

Quoting Steve Lionel (Intel)

Not quite. When we build IFWINTY, it is compiled with /align:sequence. You'll encounter a problem like this if you declare your own copy.

Ah I see now. That's what happened indeed. Sorry for false alarm.