AnsweredAssumed Answered

vrf DLL's and header files

Question asked by VRFuser on Jun 6, 2004
Sooo,

I guess the coma is needed?

Thanks, Shawn, who are you?

Rufus

-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Friday, June 04, 2004 11:00 AM
To: VRF
Subject: [vrf] Re: DLL's and header files

>>> But I'm fairly sure there should be a comma between the first float
>>> and double.

>> Yes.

> Are we sure, a float can use a double word, a single word, or ...

Certain. It's the *size* of data that's important to the stack, not the
type. sizeof(float) = 4, sizeof(double) = 8. DWORD = unsigned long = 4, WORD
= unsigned short = 2. VEE Real32 = 4, Real64 = 8.

Interpretation (type) is important for the receiver. I.e., passing an Int32
(long) to a function that expects a float will cause the function to
misinterpret the 32 bits. VEE sends an int and the function is trying to
interpret it as an IEEE format floating point number. However, it won't mess
up the stack because the size of the data is the same.

Then of course there's certain optimizations that are used at the compiler's
discretion. Passing 16 bits can sometimes mean passing 32 bits, though the
outside world never knows the difference. One usually only sees this kind of
optimization within a complete compilation unit - a dll that exports an API
doesn't usually allow this to happen, but there are wacky combinations of
options that can produce parameter lists who's sizes don't match their
declarations.

This is one of the reasons that the standard __stdcall notation appends the
total size of parameters to a function name. If you have params of int and
short, that's 6 bytes. If your function name winds up _MyFunc@8, you know
that the short param is actually using 4 bytes and the function must be
called with 8 bytes. If not, then 16 bits of the first parameter get
replaced with 16 bits of the last return address and the stack is two bytes
short when the called function returns. The result is usually a wild crash.
-SHAWN-


---
You are currently subscribed to vrf as: rwarren@amti.net To subscribe send a
blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".


---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Outcomes