🚀 go-pugleaf

Keith <kdopson@sbcglobal.net> wrote:

> Recall that you can #pragma the compiler options at will, or break
> portions of code into other module that have a single particular compiler
> control set.
>
> What I do find interesting about this is that the code generated from your
> app didn't change, but the USER32.SendMessageA action did change.
> This indicates to me that a different version of the
> USER32.SendMessageA function was provided during the link phase, or that
> somewhere in the include files is
> a definition for SendMessageA that can have varying compiled output
> depending on compiler options.

More info: If I declare the routine as:

void __stdcall WinComboBox::add(char * str) {   or '_stdcall'
   SendMessage(hwndC, CB_ADDSTRING, 0, (LPARAM) str);
}

the error persists.  If I try pragma options such as:

#pragma option push -ps

void _stdcall WinComboBox::add(char * str) {
   SendMessage(hwndC, CB_ADDSTRING, 0, (LPARAM) str);
}

#pragma option pop

the error still persists.  I am assuming that I did that correctly as I have
never used that before.  I can get the C calling convention to work by:

void _stdcall WinComboBox::add(char * str) {
   int a = 1;
   int temp = SendMessage(hwndC, CB_ADDSTRING, 0, (LPARAM) str);
   int b = 2;
   b += 3;
   a += 1;
}

If I remove the 'int temp =' or any of the assignments the program is hosed.
Very interesting, and kinda sickening.  Oh.  I see what is happening.  Flag
CF is set to '1' on the working version, and 0 when it blows up.  Evidently
CF is set to 1 whenever there has been stuff added to the stack by the
routine.  Evidentally this is accomplished by the compiler inserting a 'add
esp, -0x0c' instruction whenever the compiler sees that stuff has been added
to the stack.  So, it is a Borland problem, in that BCB fails to see that
the stack has grown for this simple instruction.  If anyone would care to
add this on quality central, as I have never bothered to subscribe, I would
appreciate it.

Thanks,
David