Jump to page: 1 2
Thread overview
win32 and struct aligment
Jun 02, 2005
bobef
Jun 02, 2005
Brad Beveridge
Jun 02, 2005
bobef
Jun 02, 2005
Brad Beveridge
Jun 02, 2005
bobef
Jun 02, 2005
Andrew Fedoniouk
Jun 02, 2005
bobef
Jun 02, 2005
Regan Heath
Jun 02, 2005
Regan Heath
Jun 02, 2005
bobef
Jun 02, 2005
Regan Heath
Jun 02, 2005
Regan Heath
Jun 02, 2005
Andrew Fedoniouk
Jun 02, 2005
Walter
Jun 03, 2005
Andrew Fedoniouk
Jun 03, 2005
bobef
Jun 03, 2005
Walter
Jun 04, 2005
Brad Beveridge
Jun 04, 2005
bobef
June 02, 2005
I have the folloing problem: in win32 headers NMPGSCROLL structure is defined as align(1). So I defined it this way

align(1) struct NMPGSCROLL
{
NMHDR hdr;
WORD fwKeys;
RECT rcParent;
int  iDir;
int  iXpos;
int  iYpos;
int  iScroll;
}

but when I have

NMPGSCROLL *s=(cast(NMPGSCROLL*)lParam);

s.iScroll is messed up no matter if align is 1 and  s.alignof says it is 4. Also if I have like that

NMPGSCROLL s=*(cast(NMPGSCROLL*)lParam);

s.alignof is 1 but values are still messed up.

Any suggestions what may be wrong?


June 02, 2005
bobef wrote:
> I have the folloing problem: in win32 headers NMPGSCROLL structure is defined as
> align(1). So I defined it this way
> 
> align(1) struct NMPGSCROLL
> {
> NMHDR hdr;
> WORD fwKeys;
> RECT rcParent;
> int  iDir;
> int  iXpos;
> int  iYpos;
> int  iScroll;
> }
> 
> but when I have
> 
> NMPGSCROLL *s=(cast(NMPGSCROLL*)lParam);
> 
> s.iScroll is messed up no matter if align is 1 and  s.alignof says it is 4. Also
> if I have like that
> 
> NMPGSCROLL s=*(cast(NMPGSCROLL*)lParam);
> 
> s.alignof is 1 but values are still messed up.
> 
> Any suggestions what may be wrong?
> 
> 
I think that all pointers will have to be alignof == 4 (at least on x86 32 bit machines), so it makes sense that NMPGSCROLL *s has alignof 4, also it makes sense that if lParam is actually a pointer then its lowest 2 bits will be zero - ie, it is also aligned on 4 byte boundrys.

My only thoughts are
1) What is the packing/alignment of RECT & does the align actually effect the packing of rcParent
2) do the s.iScroll.offsetof, etc, numbers add up?

Brad
June 02, 2005
no property 'offsetof' for type 'int'

This is what I get....

>1) What is the packing/alignment of RECT & does the align actually effect the packing of rcParent

I can't understand the question... Mixture of bad english and bad D...

In article <d7nkfi$227p$1@digitaldaemon.com>, Brad Beveridge says...
>
>bobef wrote:
>> I have the folloing problem: in win32 headers NMPGSCROLL structure is defined as align(1). So I defined it this way
>> 
>> align(1) struct NMPGSCROLL
>> {
>> NMHDR hdr;
>> WORD fwKeys;
>> RECT rcParent;
>> int  iDir;
>> int  iXpos;
>> int  iYpos;
>> int  iScroll;
>> }
>> 
>> but when I have
>> 
>> NMPGSCROLL *s=(cast(NMPGSCROLL*)lParam);
>> 
>> s.iScroll is messed up no matter if align is 1 and  s.alignof says it is 4. Also if I have like that
>> 
>> NMPGSCROLL s=*(cast(NMPGSCROLL*)lParam);
>> 
>> s.alignof is 1 but values are still messed up.
>> 
>> Any suggestions what may be wrong?
>> 
>> 
>I think that all pointers will have to be alignof == 4 (at least on x86 32 bit machines), so it makes sense that NMPGSCROLL *s has alignof 4, also it makes sense that if lParam is actually a pointer then its lowest 2 bits will be zero - ie, it is also aligned on 4 byte boundrys.
>
>My only thoughts are
>1) What is the packing/alignment of RECT & does the align actually
>effect the packing of rcParent
>2) do the s.iScroll.offsetof, etc, numbers add up?
>
>Brad


June 02, 2005
Check alignment of  NMHDR.

Andrew.


"bobef" <bobef_member@pathlink.com> wrote in message news:d7nk3e$21qj$1@digitaldaemon.com...
>I have the folloing problem: in win32 headers NMPGSCROLL structure is defined as
> align(1). So I defined it this way
>
> align(1) struct NMPGSCROLL
> {
> NMHDR hdr;
> WORD fwKeys;
> RECT rcParent;
> int  iDir;
> int  iXpos;
> int  iYpos;
> int  iScroll;
> }
>
> but when I have
>
> NMPGSCROLL *s=(cast(NMPGSCROLL*)lParam);
>
> s.iScroll is messed up no matter if align is 1 and  s.alignof says it is
> 4. Also
> if I have like that
>
> NMPGSCROLL s=*(cast(NMPGSCROLL*)lParam);
>
> s.alignof is 1 but values are still messed up.
>
> Any suggestions what may be wrong?
>
> 


June 02, 2005
bobef wrote:
> no property 'offsetof' for type 'int'
> 
> This is what I get....
> 
> 
>>1) What is the packing/alignment of RECT & does the align actually effect the packing of rcParent
> 
> 
Hmm, all members of a struct should have the property "offsetof"
http://digitalmars.com/d/struct.html

What I was trying to say before - you have a type of RECT in your struct.  I think that RECT may be another structure.  I was trying to ask you to check that the RECT structure wasn't being padded out.

For example, assume that RECT is align 4, and is
struct RECT
{
char x,y;
}
There will be 2 bytes of padding after x & y.  Now, when you embed RECT inside of your other struct, does the align(1) directive also remove the padding from RECT?  I don't know, but I would hope that it does.

Brad
June 02, 2005
struct RECT
{
LONG left;
LONG top;
LONG right;
LONG bottom;
}

and LONG is alias for int

rcParent.alignof says 4

In article <d7np1t$26up$1@digitaldaemon.com>, Brad Beveridge says...
>
>bobef wrote:
>> no property 'offsetof' for type 'int'
>> 
>> This is what I get....
>> 
>> 
>>>1) What is the packing/alignment of RECT & does the align actually effect the packing of rcParent
>> 
>> 
>Hmm, all members of a struct should have the property "offsetof" http://digitalmars.com/d/struct.html
>
>What I was trying to say before - you have a type of RECT in your struct.  I think that RECT may be another structure.  I was trying to ask you to check that the RECT structure wasn't being padded out.
>
>For example, assume that RECT is align 4, and is
>struct RECT
>{
>char x,y;
>}
>There will be 2 bytes of padding after x & y.  Now, when you embed RECT
>inside of your other struct, does the align(1) directive also remove the
>padding from RECT?  I don't know, but I would hope that it does.
>
>Brad


June 02, 2005
typedef struct {
    NMHDR hdr;
    BOOL fwKeys; // <<<<<<<<<<<<<<<<<
    RECT rcParent;
    int  iDir;
    int  iXpos;
    int  iYpos;
    int  iScroll;
}NMPGSCROLL,


BOOL is not WORD.

align(1) struct NMPGSCROLL
{
NMHDR hdr;
WORD fwKeys; // <<<<<<<<<<<<<<<<<<
RECT rcParent;
int  iDir;
int  iXpos;
int  iYpos;
int  iScroll;
}



"bobef" <bobef_member@pathlink.com> wrote in message news:d7nqij$28cl$1@digitaldaemon.com...
> struct RECT
> {
> LONG left;
> LONG top;
> LONG right;
> LONG bottom;
> }
>
> and LONG is alias for int
>
> rcParent.alignof says 4
>
> In article <d7np1t$26up$1@digitaldaemon.com>, Brad Beveridge says...
>>
>>bobef wrote:
>>> no property 'offsetof' for type 'int'
>>>
>>> This is what I get....
>>>
>>>
>>>>1) What is the packing/alignment of RECT & does the align actually effect the packing of rcParent
>>>
>>>
>>Hmm, all members of a struct should have the property "offsetof" http://digitalmars.com/d/struct.html
>>
>>What I was trying to say before - you have a type of RECT in your struct.  I think that RECT may be another structure.  I was trying to ask you to check that the RECT structure wasn't being padded out.
>>
>>For example, assume that RECT is align 4, and is
>>struct RECT
>>{
>>char x,y;
>>}
>>There will be 2 bytes of padding after x & y.  Now, when you embed RECT
>>inside of your other struct, does the align(1) directive also remove the
>>padding from RECT?  I don't know, but I would hope that it does.
>>
>>Brad
>
> 


June 02, 2005
I've had a number of these problems, I think it's just none of those things that happens when you port from C to D.

The way I go about solving them is by printing the alignment, offset and size of every member of the struct using D, then doing the same using C.

One important point to note is that your D code is linking with the DMC libraries so if the struct you are using comes from within a DMC library you should really use DMC to compile your C. (I got bit by the differences between findfirst in MSVC and DMC)

Regan

On Thu, 2 Jun 2005 20:35:31 +0000 (UTC), bobef <bobef_member@pathlink.com> wrote:
> struct RECT
> {
> LONG left;
> LONG top;
> LONG right;
> LONG bottom;
> }
>
> and LONG is alias for int
>
> rcParent.alignof says 4
>
> In article <d7np1t$26up$1@digitaldaemon.com>, Brad Beveridge says...
>>
>> bobef wrote:
>>> no property 'offsetof' for type 'int'
>>>
>>> This is what I get....
>>>
>>>
>>>> 1) What is the packing/alignment of RECT & does the align actually
>>>> effect the packing of rcParent
>>>
>>>
>> Hmm, all members of a struct should have the property "offsetof"
>> http://digitalmars.com/d/struct.html
>>
>> What I was trying to say before - you have a type of RECT in your
>> struct.  I think that RECT may be another structure.  I was trying to
>> ask you to check that the RECT structure wasn't being padded out.
>>
>> For example, assume that RECT is align 4, and is
>> struct RECT
>> {
>> char x,y;
>> }
>> There will be 2 bytes of padding after x & y.  Now, when you embed RECT
>> inside of your other struct, does the align(1) directive also remove the
>> padding from RECT?  I don't know, but I would hope that it does.
>>
>> Brad
>
>

June 02, 2005
On Fri, 03 Jun 2005 08:55:14 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> I've had a number of these problems, I think it's just none of those things that happens when you port from C to D.

Erg ... "none" == "one" (cold fingers, early morning..)

Regan

> The way I go about solving them is by printing the alignment, offset and size of every member of the struct using D, then doing the same using C.
>
> One important point to note is that your D code is linking with the DMC libraries so if the struct you are using comes from within a DMC library you should really use DMC to compile your C. (I got bit by the differences between findfirst in MSVC and DMC)
>
> Regan
>
> On Thu, 2 Jun 2005 20:35:31 +0000 (UTC), bobef <bobef_member@pathlink.com> wrote:
>> struct RECT
>> {
>> LONG left;
>> LONG top;
>> LONG right;
>> LONG bottom;
>> }
>>
>> and LONG is alias for int
>>
>> rcParent.alignof says 4
>>
>> In article <d7np1t$26up$1@digitaldaemon.com>, Brad Beveridge says...
>>>
>>> bobef wrote:
>>>> no property 'offsetof' for type 'int'
>>>>
>>>> This is what I get....
>>>>
>>>>
>>>>> 1) What is the packing/alignment of RECT & does the align actually
>>>>> effect the packing of rcParent
>>>>
>>>>
>>> Hmm, all members of a struct should have the property "offsetof"
>>> http://digitalmars.com/d/struct.html
>>>
>>> What I was trying to say before - you have a type of RECT in your
>>> struct.  I think that RECT may be another structure.  I was trying to
>>> ask you to check that the RECT structure wasn't being padded out.
>>>
>>> For example, assume that RECT is align 4, and is
>>> struct RECT
>>> {
>>> char x,y;
>>> }
>>> There will be 2 bytes of padding after x & y.  Now, when you embed RECT
>>> inside of your other struct, does the align(1) directive also remove the
>>> padding from RECT?  I don't know, but I would hope that it does.
>>>
>>> Brad
>>
>>
>

June 02, 2005
MSDN says it is BOOL but it is WORD in the ms platform sdk 2003 headers... Both of them doesn't work :)


In article <d7nrme$29cl$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>
>typedef struct {
>    NMHDR hdr;
>    BOOL fwKeys; // <<<<<<<<<<<<<<<<<
>    RECT rcParent;
>    int  iDir;
>    int  iXpos;
>    int  iYpos;
>    int  iScroll;
>}NMPGSCROLL,
>
>
>BOOL is not WORD.
>
>align(1) struct NMPGSCROLL
>{
>NMHDR hdr;
>WORD fwKeys; // <<<<<<<<<<<<<<<<<<
>RECT rcParent;
>int  iDir;
>int  iXpos;
>int  iYpos;
>int  iScroll;
>}
>
>
>
>"bobef" <bobef_member@pathlink.com> wrote in message news:d7nqij$28cl$1@digitaldaemon.com...
>> struct RECT
>> {
>> LONG left;
>> LONG top;
>> LONG right;
>> LONG bottom;
>> }
>>
>> and LONG is alias for int
>>
>> rcParent.alignof says 4
>>
>> In article <d7np1t$26up$1@digitaldaemon.com>, Brad Beveridge says...
>>>
>>>bobef wrote:
>>>> no property 'offsetof' for type 'int'
>>>>
>>>> This is what I get....
>>>>
>>>>
>>>>>1) What is the packing/alignment of RECT & does the align actually effect the packing of rcParent
>>>>
>>>>
>>>Hmm, all members of a struct should have the property "offsetof" http://digitalmars.com/d/struct.html
>>>
>>>What I was trying to say before - you have a type of RECT in your struct.  I think that RECT may be another structure.  I was trying to ask you to check that the RECT structure wasn't being padded out.
>>>
>>>For example, assume that RECT is align 4, and is
>>>struct RECT
>>>{
>>>char x,y;
>>>}
>>>There will be 2 bytes of padding after x & y.  Now, when you embed RECT
>>>inside of your other struct, does the align(1) directive also remove the
>>>padding from RECT?  I don't know, but I would hope that it does.
>>>
>>>Brad
>>
>> 
>
>


« First   ‹ Prev
1 2