Yeah, I'm slownly working toward a solution to the problem, yet some stuff should still find an issue : 1- #pragma pack(8) align on a 8-byte boundary members of size >= 8, it doesn't add padding byte (what is in fact not a problem) 2- #pragma pack(1) align on a 1-byte boundary every members, nice for sending/receiving the struct as a frame. However that show the problem of software alignment fault on FPU members (float, double) and members whose size is greater than the current architechture word 3- #pragma pack(2) might lift up the problem upon most cases, but FPU members still get troubles 4- anonymous union is a nice stuff, yet I not always own the headers. Understand I work with compiled third party libraries and their header file. I work with struct coming out from these header files, and while I need the native format to deal with the library, I'd like to use the struct definition as a skeleton for my message's declaration as well. I 'just' need to enforce that the format of my message will be both 32 and 64 bit compatible (best is packing on 2 with 64 bits pointer).

#include <>

/* ======== foreign_lib.h ========
typedef struct foreign_struct
{ char nMode;
float fValue;
int* pArray;
};

foreign_struct* get_struct(void);
=== I HAVE NO CONTROL OVER THIS === */

// int send_frame(void* pBuffer, size_t nSize);

int test_struct(foreign_struct* frame)
{
#pragma pack(2)
struct foreign_struct sFrame;
#pragma pack()

// foreign_struct : native struct format
// sFrame : my packed struct frame

if(send_frame(frame, sizeof(foreign_struct))
== send_frame(&sFrame, sizeof(sFrame)))
return (int) TRUE;
else
return (int) FALSE;
}

int main(int argc, char *argv[])
{
return test_struct(get_struct());
}

But thanks for you offer, good stuff to know ! Kochise

In Code we trust !

Yeah, the root of the problem is that I'm currently writing a generic linked-in driver for Erlang that should adapt to any kind of platform, be it 32 or 64 bits. Imagine the client side to be 64 and the server side to be 32 bits, of course the pointers provided in the structs can only be used locally, yet if the server needs a data chunk from the client side, it just have to request it using its handle (the pointer). That's why both side MUST have the same struct layout, so that the 32 bits server could catch up the valid 64 bits pointer from the raw piece of data extracted from the up-coming message, then send it back in a 'hands-up and gimme your memory' kinda request (handshake). I imagine it would be kind to pack the whole struct in a #pragma pack(1) fashion for message-passing, yet rendering it useless for run-time usage due to alignment fault that could arise. And packing/unpacking structs while they are sent/read is NOT the solution, the best would be to get them correctly shaped from the very beginning, the extra (wasteful) padding bytes included :/ Problems arises as the size but also the alignment of data change between a 32 and 64 bits architechture, what makes things a bit over complicated to my taste : http://docs.hp.com/en/5966-9844/ch03s02.html I would like to avoid requiring the use of an extra library, because one might lead to require another one, leading to a complete mess. I'm a macro freak, and if some well defined macros do the job, I'm pretty for that kind of solution. Kochise

In Code we trust !

modified on Friday, July 17, 2009 11:50 AM

Reading elsewhere, seems there is a 'dirty tricky trick' that might do the job (unless verified more thoroughfully) :

typedef struct{ // size, offset 32 bits, offset 64 bits
int nCount; // 4, 0, 0
short nMode; // 2, 4, 4 <- ???
sHue sColor; // 8, 8, 8
char* pTest; // 4, 16, 16
__declspec( align(8))
char aData[10]; // 10, 24, 24
}sStack,*psStack; // 28 (real) -> 40 (sizeof 32 bits), 40 (sizeof 64 bits)

Do you understand that ? However that doesn't works in every compiler, I need something more portable, such like a WORKING #pragma pack option... Kochise

In Code we trust !

modified on Friday, July 17, 2009 7:32 AM

Hello folks, I'm encountering a problem. Doing message-passing, I'm sending/receiving buffers from various/mixed architectured machines (32 and 64 bits). I first tried to use this as a buffer skeleton :

typedef struct{ // size, offset 32 bits, offset 64 bits
int nCount; // 4, 0, 0
short nMode; // 2, 4, 4 <- ???
sHue sColor; // 8, 8, 8
char* pTest; // 4, 16, 16
char aData[10]; // 10, 20, 24
}sStack,*psStack; // 28 (real) -> 32 (sizeof 32 bits), 40 (sizeof 64 bits)

On a 32 bits platform, if aData is grown to 12, it fits the whole struct size (12 bytes from offset 20 = 32), thus growing it to 13 push the struct's end to 36 (4 bytes alignment). However I *NEED* the struct to be exactly the same size, whenever this code runs on a 32 bits machine or, you might have guessed it, a 64 bits one. So I tried :

#pragma pack(8)
typedef struct{
[...]
}sStack,*psStack;
#pragma pack()

Yet it just doesn't works like expected on a 32 bits build. The struct's size is still 32 bytes, whereas I expected at least 36 (pTest pointer using 8 bytes, thus aData lying at offset 24, hence growing the struct to 34 bytes, aligned to 36 bytes). stdcall or cdecl calls should remains set to 32 or 64 bits accordingly to the native platform, that means a ((psStack)buff)->pTest instruction shouldn't need to be casted for suiting 32 or 64 bits build. I just need the pointers in struct to be casted to the size of an __int64 (with the needed 4 padding bytes) ! Any luck someone to have a hint, a trick, or just the full answer ? Thanks anyway... Kochise

In Code we trust !

String in my hands, pleases we-mean : String MyHands = new String("Please who-men"); Kochise PS : Find the "bugs" in my string or my hands...

In Code we trust !

This stuff is stunning, not even a line of comment ! Kochise

In Code we trust !

In good forums I'm used to log in, when you post a URL, it is automatically parsed and made clickable. Perhaps a matter of forum settings, I don't know... Kochise

In Code we trust !

If he can't copy/paste, I think he shouldn't even bother coding. I'm not here to wipe his nose (or other ends) when it's messy, or prechew his meat to feed him like a young bird... Kochise

In Code we trust !

See http://www.codeproject.com/lounge.asp?msg=2029905#xx2029905xx ! Answer : because there is even more inefficient architects/managers that hire them... Kochise

In Code we trust !

Repeat yourself here instead : http://www.codeproject.com/script/comments/forums.asp?forumid=3785 Kochise

In Code we trust !

It's one of my coding rules, which is really useful once you get the point :

if(NULL != l_poStrTest)
{ // Format error message
l_poStrTest->Format
( "My code : %d"
, l_nErrorCode
);
}
else
{ // Error code
}

It's also all about defines :

#define MY_TEST

#ifndef MY_TEST
int l_nSize = GetStringSize(l_poStrText);
#else // MY_TEST
// int l_nSize = TempoFunc(l_poStrText);
#endif // MY_TEST

By doing so, I write the full structure of the code which is then ready to fill up, and it also helps to keep an eye-track of the execution logic (inequal statement first) so that you don't have to know if the test is about inequality (!= or #ifndef) or equality (== or #ifdef). You just have to spot the upper or lower block of code and see if it is defined/filled or not... This also force to structure carefully your code and put some air between the lines, instead to write a rock-compact block of code... Kochise PS : I often write empty equality code like this

if(NULL != l_poStrTest)
{ // Format error message
l_poStrTest->Format
( "My code : %d"
, l_nErrorCode
);
}
else{} // Error code, ready to be unrolled and filled with error handling code

In Code we trust !

It was about to become really costful, as he was paid on the number of lines he was writing. He even managed to write wrappers over each native Win32 API, even the ones he was not using, just to charge more... And above this, he planned to rewrite Windows in a VM ! That's an explanation, find more :) Kochise

In Code we trust !

Yeah, since I'm currently writing my own C compiler (not yet C++), I found very interresting coding tricks being just possible/allowed by the standard. It's fun, permisive and very powerful ! Kochise

In Code we trust !

Ask Kernighan and Ritchie or even Stroustrup why they allowed it ! Don't complain if the compiler don't... Kochise

In Code we trust !

Use C's "delayed assignement" : TCHAR szProp1[256]; TCHAR szProp2[256]; DWORD dwSize; MsiGetProperty(hMsi, "Property1", szProp1, **&(dwSize=256)**); MsiGetProperty(hMsi, "Property2", szProp2, **&(dwSize=256)**); or even : TCHAR szProp1[256]; TCHAR szProp2[256]; DWORD dwSizeProp1; DWORD dwSizeProp2; MsiGetProperty(hMsi, "Property1", szProp1, **&(dwSizeProp1=dwSizeProp2=256)**); MsiGetProperty(hMsi, "Property2", szProp2, **&dwSizeProp2**); It looks weird at first, but it works and avoid several bugs of this kind ! Kochise

In Code we trust !

"to suit his hippy ideals.", nope : to suit his COMMUNISM ideals ! GPL addicts' favorite claim is : "All your code belongs to us !" If they dared to make the addition GPLed, imagine that every part of code should be now 'open' for their own benefit ! Kochise

In Code we trust !

Oh, OK, what you provided were RAW floating point numbers (I'm used to see them in their RAW format, and it don't struck my eyes) :

0xFFFFFF00
0xFFFFFEFF

I think my macro should work on them :

#define FCMP(x,y) (*((int*)&x)&0xFFFFF800)==(*((int*)&y)&0xFFFFF800)

float dSecondValue; *((int*)&dSecondValue) = 0xFFFFFF00; // RAW : 0xFFFFFF00
float dTest2; *((int*)&dTest2) = 0xFFFFFEFF; // RAW : 0xFFFFFEFF, last 11 bits are differents, so don't compare them -> 0xFFFFF800
ASSERT(FCMP(dSecondValue,dTest2)); // *NO* Crash

I just tested, my macro works really well, even if what you provided are not numbers but QNAN. But let me tell you, WHAT THE F... my macro have to be useful on testing QNAN ? These are not numbers and should not be used ! You should throw an error instead, catch it in an ASSERT if you want, but from me to you, your example is just here to try to find a flaw in my trick, which only remains a trick, and show everybody how I'm bad in finding solutions. Bad move... Kochise

In Code we trust !

My macro can be of great help if you know where you put your foot. Eg when dealing with strict positive numbers set, or strict negative numbers set, without mixing the two. However the test case only works with 0xFF... values padded with 0, not like your 0xFFFFFEFF example. I think you wanted to say 0xFFFFFE00 which is correct :) Kochise PS : If I remember right, there is a 'magical trick' explained in a raticle on CP which explain how to cast double to float and the way back only using integer operations, and it works pretty well and fast, and also deals with the sign...

In Code we trust !

Try this, this is what I use in every of my code :

double dValue = atof("0.1");
double dTest = 0.1;
ASSERT
(
((*((LONGLONG*)&dValue))&0xFFFFFFFFFFFFFF00)
== ((*((LONGLONG*)&dTest)) &0xFFFFFFFFFFFFFF00)
);

double dSecondValue = (1 + dValue + dValue + dValue + dValue);
double dTest2 = 1.4;
ASSERT
(
(*((LONGLONG*)&dSecondValue)&0xFFFFFFFFFFFFFF00)
== (*((LONGLONG*)&dTest2) &0xFFFFFFFFFFFFFF00)
); // *NO* Crash

By reducing mantissa's complexity (skiping lasting bits) by an interger cast (mostly like an union over a double), you can do some pretty decent comparison with no headache... By using float (4 bytes) instead, you could simply things to :

float dValue = atof("0.1");
float dTest = 0.1;
ASSERT
(
((*((int*)&dValue))&0xFFFFFFF0)
== ((*((int*)&dTest)) &0xFFFFFFF0)
);

float dSecondValue = (1 + dValue + dValue + dValue + dValue);
float dTest2 = 1.4;
ASSERT
(
(*((int*)&dSecondValue)&0xFFFFFFF0)
== (*((int*)&dTest2) &0xFFFFFFF0)
); // *NO* Crash

The problem comes mostly because the preprocessor code which convert double dTest = 0.1 is *NOT* the same than the code within ATOF which convert double dValue = atof("0.1"). So you don't get a bitwise exact match of the value, only a close approximation. By using the cast technique, you : 1- can control over how many bits how want to perform the comparison 2- do a full integer comparison, which is faster by far than loading floating point registers to do the same 3- etc... So define the following macros :

#define DCMP(x,y) ((*((LONGLONG*)&x))&0xFFFFFFFFFFFFFF00)==((*((LONGLONG*)&y))&0xFFFFFFFFFFFFFF00)
#define FCMP(x,y) (*((int*)&x)&0xFFFFFFF0)==(*((int*)&y)&0xFFFFFFF0)

Use DCMP on double, and FCMP on float... But beware, you cannot do that :

ASSERT(DCMP(atof("0.1"),0.1)); // atof returns a value which have to be stored...

The following code works :

#define FCMP(x,y) (*((int*)&x)&0xFFFFF000)==(*((int*)&y)&0xFFFFF000)

float dSecondValue = atof("1.4"); // RAW : 0x3FB332DF
float dTest2 = 1.39999; // RAW : 0x3FB33333, last 12 bits are differents, so don't compare them
ASSERT(FCMP(dSecondValue,dTest2)); // *NO* Crash

Kochise EDIT : you may have used a memcmp approach, which is similar in functionality, but you can only test on byte boundaries (base of lenght of comparison is byte) and x86 is little endian, so you start comparing the different bytes first,

...that covers this : Johnny Mnemonic Strange Days ... Kochise

In Code we trust !