I presume you mean (myVar == false) since myVar = false is an assignment <g>

Zero is false.  Non zero is true.  This is a defined by the C++ langauge
spec (AFAIK).  It doesn't matter that VC++ defines bool to 1 byte...it could
be 8 bytes for all that it matters....the language defines it.

On the other hand, you have to ask yourself why the caller is sending you a
"3" when you have declared your interface function to accept only a bool.
The 'bool' has a specific (compiler defined) data type that should only
accept a 'true' or 'false' (also compiler defined values) in the C++ world.
In a "perfect" world, a bool datatype would be 1 bit (of course it's
not...in fact it's probably 32 or 64 bits depending on the computer's
architecture).

After rereading your post, and thinking about it some more:

Are you REALLY sure you want to expose C++ data structures/functions from a
DLL?  You are pretty much limiting the users of your library to the specific
version of the compiler used to generate the library, since name mangling
has changed (at least in my experience) in every version since 6.0...

Better to extern "C" everything and use standard C types in all data
structures <G>

Hi Bob,

This is an interesting question.

In language level, the C++ bool type is defined as one byte. This can be
easily confirmed with:
printf("Size of bool: %d\n", sizeof(bool));

So, once the VC++ compiler sees bool type, it will cut any value greater
than a byte into single byte. Let's take the following sample code as an
example:
void Test(bool test)
{
    printf("Size of bool: %d\n", sizeof(bool));
}

int _tmain(int argc, _TCHAR* argv[])
{
    int i = 10000000;
    Test(i);
}

The VC++ compiler will emit the assembly code below:
 cmp         dword ptr [i],0
 setne       al  
 push        eax  
 call        Test (41122Bh)
 add         esp,4

As you can see, the VC++ compiler will use compare the input value with
zero and only set the single byte "al" register for using with the bool
type. This obeys the single byte rule.

Let's come back to your specific problem. If the code goes across the DLL
boundary, there is another story. The answer for your question is not
consistent. Let's explain.

When your DLL project is compiled into a DLL binary file, all C++ type
information is lost. There is only binary code in the DLL. Since the x86
platform Windows requires the parameters to be passed in 4 bytes aligned.
Even your function parameter is of type "bool", the compiler will reserve a
4 bytes space for this parameter. Now, in the Exe project, if the caller
pushes a value larger than 1 byte and less than 4 byte, Windows will accept
it without any problem, no crash or corruption will occur. Sure, this
depends on whether the Exe caller will push a value larger than 1 byte. If
the caller also declares the parameter as a C++ bool type(assume the caller
is also a C++ language), I think the caller compiler will also use some
type of trick(like the assembly code above used by VC++ compiler) to only
pass a single byte value to your DLL exported function.

Note: if you wrap the bool type in a C++ structure, union or class, the
compiler may not align the bool type at 4 bytes by using "#pragma pack(1)".

Yes, I agree that we'd better use Windows BOOL type for export so that we
will not confuse with this problem.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.