Profibus DLL implementation doesn't work

[cordm]

There is a neat macro called offsetof that takes padding into account.

[MaSta]

---

@cordm wrote:

There is a neat macro called offsetof that takes padding into account.

---

Nice! Didn't know that one. However, I have troubles to implement the macro. The definition is 

offsetof(struct structname, structmember)

The struct is defined as

typedef struct {} DP_DATA;

declared as

DP_DATA FAR DpData; 

and so I thought that 

printf("C1_Response_Timeout: %zu\n", offsetof(DpData, C1_Response_Timeout));

should work, but it doesn't.

[MaSta]

---

@rolfk wrote:

C1_Response_Timeout is an int and as such only uses 4 byte (on every current platform with the exception of some 8 bit embedded CPUs). Because of that it is aligned on a 4 byte boundary even if the default alignment is set to 8 byte!

---

According to the binary data read from stDpData, that struct member is where I expect it, at offset 3:

[rolfk]

What strange C compiler are you using? int has been NOT a 16-bit entity since Windows 95 back in the mid 90-ies!!!! It was a 16-bit value in Windows 3.x and still is in some 8-bit embedded CPUs, but is at least 32-bit on every modern 32-bit CPU. And it has stayed a 32-bit integer even in 64-bit Windows and Linux.

That 0 is the filler byte, and the data is in little endian format, with the value 0x64 being the lowest significant byte of the 32-bit integer, respectively the 4 byte integer. The next 3 zeros bytes are the higher significant bytes of that integer.

If you want to read numbers in a memory dump as they are listed, you need a Big Endian CPU. But Intel x86/64 is the main CPU in everything nowadays and the only other fairly present ARM CPU, while it allows either endianess to be used, they have standardized on Little Endian too, simply to avoid byte order trouble when porting code from Intel x86/x64. Complain at Intel that they used Little Endian and managed to dominate the CPU market so that the Big Endian format got pretty much squashed. 🙂

Motorola and Power PC used to be Big Endian, but they didn't manage to survive in the general PC market, even though there were for quite some time much more Power PC powered devices out there, since it was not as much of a heater device than the Intel CPUs and therefore used a lot in embedded devices such as printers and routers.

[MaSta]

I see, little endian causes this. Ok, so there is not three bytes after but one fill byte before that int.